On Saturday, 12 May 2018 at 13:38:18 UTC, Walter Bright wrote:
Mike's right. D's encapsulation model is designed around the
module.
Actually, that is not true. If it were true, then I could do:
------------
module test;
void main() { i = 2; } // sorry, but i belongs to another unit
of encapsulation
void foo() { int i = 1; }
------------
D only breaks the encapsulation properties of classes, not
functions.
Since the vast majority of programmers use classes as the basis
for encapsulation, this surely presents a significant problem to
those coming over to D, rightly expecting that encapsulation to
be retained.
If a module is too large to be comprehended, it should be
broken up into smaller modules, each with its encapsulated
functionality.
But that's why we have functions and classes - which are their
own level of smaller units of encapsulation. Blurring the
boundary of encapsulation seems like a big step backward in terms
of structured programming.
Each unit of code (a function, a class, a module) should respect
the encapsulation properties of each other.
There's simply no point in using classes in D, as they have no
capacity to encapsulate themselves (whereas function still retain
this privilege)
Now if 'private' meant 'private to the class' (as most people
would rightly expect), and the default if you had no attribute
was, say, 'accessible to the module', then I could probably live
with that, and I would start to use classes in D productively.
But when the class has lost its capacity to encapsulate, it's
lost its purpose.
It is hard enough to hold a class in working memory so you can
reason about.
Making us hold whole modules in memory so we can reason about the
interaction between classes and modules, is just nonsense, in my
opinion.
