Non-ugly ways to implement a 'static' class or namespace?

[ProtectAndHide]

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.