On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
Data hiding is overrated.
...
Actually, data hiding is at the core of using objects, and
objects are at the core of doing OOP.
" Hiding internal state and requiring all interaction to be
performed through an object's methods is known as data
encapsulation — a fundamental principle of object-oriented
programming."
https://docs.oracle.com/javase/tutorial/java/concepts/object.html
D can 'provide' that encapsulation. That is true. But it does it
**indirectly**, by requiring the class representing that object
to not have any other code in the module containing that class.
If there is any other code in the module with that class
(including unittests), then that class is no longer encapsulated.
There should be no argument as to whether the statements above
are correct or not. They are clearly correct.
The only objection people can reasonably raise, is whether its ok
to provide encapsulation in this manner (i.e. indirectly), or
whether the language should provide a mechanism whereby the
progammer can 'declare' the encapsulation.
It should not come as a surprise, given C++, C#, Java, Swift,
Javascript.. .. ... that a programmer might want to have more
explicit access control... since they have it in those languages
... and those languages represent the vast majority of the worlds
programmers.
What is surprising, is the level of objection in the D community
to allow such an option in D.
Since the majority of programmers in the world HAVE this option
already, there will be continued debate over this issue, should
they ever come and have a look at D. That much is certain.
But the debate should not be about whether a programmer needs to
encapsulate their object. That is a choice the programmer should
make. It's a design decision for them, not for others.
The debate should be whether those programmers should be FORCED
to put each and every class in its own modules. That's a design
being forced on the programmer in order to get encapsulation of
that object.
D forces a 1:1 mapping of class to module in order to provide
object encapsulation. That is what I don't like. Keep in mind,
this also means unittests must be in a separate module as well,
as the unittest in the same module as the class, means the class
is no longer encapsulated (i.e. the compiler cannot assist you -
in relation to type safety - when you accidently reference a
private member - which is what I did when I first came to D - and
hence, is the reason for my raising this as an issue in the first
place).
I think this thread has lost any usefulness, because many try
redirect the issue at hand to something else completely. But this
post summarises the problem well enough for everyone to
understand - and choose their side ;-)
