Non-ugly ways to implement a 'static' class or namespace?
ProtectAndHide at gmail.com
Wed Feb 15 19:44:50 UTC 2023
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
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
> 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
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
As a programmer, I don't think that is acceptable.
More information about the Digitalmars-d-learn