Module-level privacy

[Jonathan M Davis]

On Sunday, May 13, 2018 17:19:26 rumbu via Digitalmars-d wrote:
> On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote:
> > Also, someone may say: I can see what happens in one and the
> > same file. If there are two classes/structs in one file, they
> > are "friends" and I dont need the "friend"-keyword anymore.
> > Thats an argument, too.
>
> So, when you have 1000 classes, you just create 1000 files just
> to "unfriend" them :)

Which is basically what you get in Java, though no one should be putting
1000 classes in a single module anyway. But if you want to make it so that
classes can't access each other's members while still making it possible to
import them together, then all you have to do is have a module which
publicly imports all of those other modules which have one class each.

The only thing that you really lose with D's approach as opposed to friend
is that D doesn't provide a way to mark something from another module as a
friend. package at least partially solves that problem though. Really, what
D went with is similar to what Java did, only it's more flexible, because it
doesn't restrict what can go in a module, whereas Java only allows one
public class per module and doesn't have any free functions.

Ultimately, D's solution simplifies things over what C++ did with friends
while giving you basically the same level of control. It's just that if you
don't want something to be able to access the private members of a class or
struct, that symbol must be in a separate module. So, if you _really_ don't
want anything accessing the internals of your class or struct, but you want
to be able to stick stuff in the same file, then that can get annoying,
because you can't do that. But public imports let you make it so that you
can still import them as one even if they're not actually in the same file,
and many of us have found that having the default be that other stuff in the
module can access the private members to be very useful - especially with
regards to testing.

I fully expect that if we added some sort of "super private" that really
made it so that nothing outside a class or struct could access its members,
almost no one would use it, and it wouldn't really solve much in the way of
real problems, much as I'm sure that a few folks like KingJoffrey would be
quite happy to have something like that.

Ultimately, there are tradeoffs between what C++ did and what D did, and
neither approach is perfect, so some folks are likely to be happier with one
approach over the other, but overall, what D has done has worked extremely
well for D.

- Jonathan M Davis