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

[ProtectAndHide]

On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
>
> Data hiding is overrated.
> ...

Actually, data hiding is at the core of using objects, and 
objects are at the core of doing OOP.

" Hiding internal state and requiring all interaction to be 
performed through an object's methods is known as data 
encapsulation — a fundamental principle of object-oriented 
programming."

https://docs.oracle.com/javase/tutorial/java/concepts/object.html

D can 'provide' that encapsulation. That is true. But it does it 
**indirectly**, by requiring the class representing that object 
to not have any other code in the module containing that class. 
If there is any other code in the module with that class 
(including unittests), then that class is no longer encapsulated.

There should be no argument as to whether the statements above 
are correct or not. They are clearly correct.

The only objection people can reasonably raise, is whether its ok 
to provide encapsulation in this manner (i.e. indirectly), or 
whether the language should provide a mechanism whereby the 
progammer can 'declare' the encapsulation.

It should not come as a surprise, given C++, C#, Java, Swift, 
Javascript.. .. ... that a programmer might want to have more 
explicit access control... since they have it in those languages 
... and those languages represent the vast majority of the worlds 
programmers.

What is surprising, is the level of objection in the D community 
to allow such an option in D.

Since the majority of programmers in the world HAVE this option 
already, there will be continued debate over this issue, should 
they ever come and have a look at D. That much is certain.

But the debate should not be about whether a programmer needs to 
encapsulate their object. That is a choice the programmer should 
make. It's a design decision for them, not for others.

The debate should be whether those programmers should be FORCED 
to put each and every class in its own modules. That's a design 
being forced on the programmer in order to get encapsulation of 
that object.

D forces a 1:1 mapping of class to module in order to provide 
object encapsulation. That is what I don't like. Keep in mind, 
this also means unittests must be in a separate module as well, 
as the unittest in the same module as the class, means the class 
is no longer encapsulated (i.e. the compiler cannot assist you - 
in relation to type safety - when you accidently reference a 
private member - which is what I did when I first came to D - and 
hence, is the reason for my raising this as an issue in the first 
place).

I think this thread has lost any usefulness, because many try 
redirect the issue at hand to something else completely. But this 
post summarises the problem well enough for everyone to 
understand - and choose their side ;-)