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

[zjh]

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. A common 
> recommendation in Java used to be (and probably still is) to 
> always accessing private members by their setters even inside 
> the class. And after all these years they haven't had a need to 
> lock down single-method access to private members. It's the 
> *exact* same thing 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.
>
> We keep repeating the same arguments over and over and over 
> again on this. I still haven't seen any convincing argument for 
> changing things when it's already possible to do what you want 
> to do. I repeat for the umpteenth time: if you care so much 
> about who can touch your private parts, then put your classes 
> and structs in their own modules and use D's package facilities 
> to provide the public interface you want.


Class level private, which can ensure that there will never be 
any leakage and there will be no encapsulation misuse,
At the module level, this is unavoidable!
And there are closely related classes, which should be placed in 
a module.