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

[RTM]

On Friday, 17 February 2023 at 22:58:19 UTC, ProtectAndHide wrote:

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

Let's look at Stroustrup's definition:

```
Object-oriented programming is programming using inheritance. 
Data abstraction is programming using user-defined types. With 
few exceptions, object-oriented programming can and ought to be a 
superset of data abstraction.
```

Data hiding is orthogonal to OOP. It can be used without 
inheritance, on struct members. Inheritance can be used without 
it.

> 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.

It's the old way, the first attempt. A mistake. Modern 
programming languages tend to implement it differently, or even 
reject.

For example, in Google's Dart it was explicitly rejected:

https://github.com/dart-lang/sdk/issues/33383
```
It's not the first time this has been requested, but we have no 
current plan to add such keywords.

There is a reason Dart does not use class based privacy.
Dart allows dynamic invocations. If you write dynamic x = 
someObject(); x.foo; then the foo access does not know the class 
of the object in x. It must work independently of that.
Now, if x has a class with a private foo, should that function 
then be found? That depends on whether the access x.foo is inside 
that class. If it's protected, then it depends on whether the 
access is inside a subclass of the declaring class. That adds a 
lot of overhead to dynamic accesses. It's not impossible, but 
it's just not something that the Dart language is well suited for.

The library based privacy that Dart has is allows us to 
syntactically detect private member accesses, and use renaming 
per library to allow a more efficient implementation of dynamic 
access.

If we ever add some other sort of privacy, it's more likely to be 
instance based than class based. That means that you can only 
access such members through this or super, which ensures that we 
always know the type of the receiver and we avoid dynamic 
accesses.
```

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

No offense, but it looks like your surprise comes from your 
inexperience.