On Wednesday, 23 November 2022 at 09:51:46 UTC, FeepingCreature
wrote:
The module is the capsule. D is simply not interested in
building a capsule around a class. D does not let "anyone" pass
through, it lets "anyone in the module" pass through, because
the module is the wall. I think this is a stronger concept of
encapsulation than C++ friends because the encapsulation is
lexical rather than just declarative.
But if I write a class specification, then that class will be its
own capsule.
It will be its own type, just like a built in type.
It will have its own interface by which other code can interact
with it, just like a built in type.
Why then should a programming language insist that all other code
in the module should be able to bypass my specification, and do
as it pleases to my type?
If this applied to built in types, imagine the chaos that could
follow from that.
Well, the class is a type as well.
I struggle to see how treating other code in the module as though
it is a part of the specification of my type (ie. all that code
is essentially inside the perimeter of my class type), benefits
me as software engineer.
I am surely missing something here.
In C++, if I want another type to interact with my type, in a
tightly coupled manner, then I can explicately authorise that
interaction very easily, using friend. Now when I see my code, or
others read my code, they know intent.
In a D module, intent cannot be discovered so easily, since it
cannot be explicately declared. Not even the compiler knows your
intent. It can only assume everything you typed in the module is
correct. And now your counter class overflows...and boom!
