On Sunday, 28 October 2018 at 05:28:31 UTC, Mike Parker wrote:
>
> You can make the same mistake inside the class:
>
> class Foo {
> private int x;
> void increment() {...}
> ...
> void doSomethingInternal() { x++; }
> }
>
> How is making that mistake outside of that final curly brace
> any different or any worse? It's all in the same file.
Except, that (I assume) a module in D is meant to be more than
just a single class.
If that's not the case, then my argument is irrelevant.
If it is the case, then you presumably would have a great deal
more code in your module, than you would in a single class.
Hence, greater likelihood of mistakingly
accessing a private member of some class defined within the
module, somewhere.
In any case, it does undermine the principle of encapsulation
(assuming you agree that a class deserves to be a unit of
encapsulation).
In, it's nothing more than a convenient hack, really.
There is not a third option here.
The advantage of the Way D does things is that you don't have to put your data into a class and instantiate it in order to have encapsulation.
In C++ for instance often data is put into a class just to have encapsulation, this has a cost in resources as well the complexity of program.
In D any data that there only needs to be one copy of and lasts the lifetime of the program belongs in a module rather than a class.
In practice this tends to mean less classes, and less of the work done inside classes.
D source code can feel inside out compared to C++ source code.