On 3/12/18 10:06 PM, psychoticRabbit 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.

OK, so I agree there are drawbacks. But these can be worked around.

In fact, the language author touted this article as sage advice, when in D it's pretty inconvenient: https://forum.dlang.org/post/osr2l3$1ihb$2...@digitalmars.com

But when you get right down to it, where you draw the line is arbitrary. Given the power to encapsulate on module boundary, you have lots of different options as to where your functions can reach. You can pretty much put anything into a module, so you aren't limited to class members which can access specific data. With the advent of package modules, you can control quite finely what functions have access to what items, and still have nice simple imports.

If you limit to class members, then you have to do something like C++ friends, which are unnecessarily verbose.

IMO, the module-level encapsulation is the right choice. It helps with a lot of key features:

1. IFTI factory methods
2. unittests
3. co-related structs/classes


Reply via email to