On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
I referenced that in my post. The exact same problem exists
*inside* the class when your class file is very long. You can
easily manipulate the private member even when it's only
supposed to be accessed by a specific function.
You're missing the point, completely.
We're discussing the issue of type safety.
Your talking about typing mistakes.
.. in D: the private implementation is in the source file. The
fact that the source file represents a module rather than a
single class is irrelevant.
Again, this is about type safety, supported by the compiler.
Read that article by Stroustup that I cited, so you can obtain a
clearer understanding what it is 'he' is saying, because what I
am saying.
In essence, he discusses how inferior a type created through a
module mechanism is, compared to a user-defined type (and that
user-defined types were provided by languages for that very
reason). The key being, that user-defined types provide their own
mechanism for data hiding (the representation is private). D's
module system supports this, but it does not 'enable' it. i.e. it
supports it by forcing the programmer to put that type into its
own module.
We keep repeating the same arguments over and over and over
again on this......
That's because the key idea being presented here, is not being
taken on board.
A user-defined type is a type that has a mechanism to keep it
representation private.
D does not support this. It only enables it.
You (and others) may well argue that D should not enable this
(directly), it should only support it (indirectly), and thus
allow the language to force an important design decision onto
programmers.
As a programmer, I don't think that is acceptable.
