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