On Friday, 11 May 2018 at 16:51:30 UTC, Mike Parker wrote:
On Friday, 11 May 2018 at 14:05:25 UTC, KingJoffrey wrote:
private is not private at all in D, and because of this,
classes are fundamentally broken in D (by design apparently).
Now.. I really do have better ways to spend my time. I've made
my point. Nobody who uses D seems to think in a similar way,
apparently, so I leave it at that.
Classes are *not* broken in D. The module is the lowest level
of encapsulation and provides exactly what encapsulation is
supposed to provide -- the ability to hide the implementation
from the outside world so that it may be changed without
breaking the API. Being able to access private class members in
the same module does not break encapsulation.
Yes, it does.
The first example is unit testing. Having access to the private
members of a class inside the same module is a mistake because it
breaks the idea of encapsulation. Unit testing must be done
exclusively on public members of a class. If you are feeling the
urge to test a class private thing, there is something wrong with
your class design. In the parallel world of true OOP which D
tries to avoid as much as possible there is a saying for that:
"Everytime you test a private method, a unicorn dies".
The second example is inter-class access of private members if
you have multiple classes in the same module. The "define a class
per module" is not a solution in this case because D lacks the
idea of namespace an it's just ridiculous to have a library with
1000 different modules just to achieve real class encapsulation.
The third example is pollution of IDE code completion in the same
module with members which are not meant to be there.
