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

[Mike Parker]

On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote:
>
>
> What if two classes in the module that are several meters apart 
> make `mistakes` that change the privite variable of `another 
> class`?
>
> No one can guarantee that after `a few months`, even if you are 
> the author, you will not make mistakes, so as to misuse private 
> variable, while `class level` private can be completely avoided 
> it!
>
> There is no maintainability, because two `out-of-class` 
> functions may quietly change your private `variables`.

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.