how to make private class member private

[Jonathan M Davis]

On Tuesday, March 13, 2018 02:06:57 psychoticRabbit via Digitalmars-d-learn 
wrote:
> On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
> > private is private to the module, not the class. There is no
> > way in D to restrict the rest of the module from accessing the
> > members of a class. This simplification makes it so that stuff
> > like C++'s friend are unnecessary. If your class in a separate
> > module from main, then main won't be able to access its private
> > members.
> >
> > - Jonathan M Davis
>
> Mmm.. I don't think I like it.
>
> I feel you should be able to make a member of a class, private,
> regardless of where the class is located. This seems to break the
> concept of class encapsulation.
>
> No. I don't like it at all.

Well, this thread sure blew up fast...

The decision to make private restrict access to the module certainly has
pros and cons, but it works well over all. C++'s solution using friend is
more flexible, but it's also more complicated. D's solution removes that
extra complication. It also makes the use of private throughout the module
more consistent, since unlike C++, D has modules and has to worry about the
access level of symbols within a module and not just within classes. Also,
given D's built-in unit testing features, being able to have unittest blocks
within the module access anything within the module makes testing much
easier. No one has to muck with access levels to make stuff available to
unit tests as is often the case with languages like Java. And while it might
initially seem annoying that you can't restrict access of a member to a
class or struct even within a module, it's something that most of us have
found to not be a problem in practice. But as with all design decisions,
there are tradeoffs, and different people have different opinions about
which tradeoffs make the most sense.

The only case I'm aware of where I'd consider the current design to be a
problem is that if all of your testing is done within the module, it's
harder to catch cases where you screwed up the access level and made
something private when you didn't mean to. Being able to access all of the
private stuff for tests can be extremely useful, so it's certainly not the
case that simply making it so that unittest blocks had only public or
package access would be a clear improvement, but it's also not the case that
the current design doesn't come with any downsides.

If you really want to restrict access to the class itself, then you can
always just declare a class in its own module just like Java forces you to
do. That might be annoying if want to put several classes in the same module
while restricting their access, but it is a way to enforce full
encapsulation if that's what you really want.

Ultimately though, for better or worse, D considers the module to be the
primary unit of encapsulation in the language, and most of us find that it
works quite well. Given time you may find that you don't mind it as much -
or not, but that's the way that D does it, and I very much doubt that that's
ever going to change.

- Jonathan M Davis