Sealed classes - would you want them in D?

[rumbu]

On Friday, 11 May 2018 at 16:51:30 UTC, Mike Parker wrote:
> On Friday, 11 May 2018 at 14:05:25 UTC, KingJoffrey wrote:
>
>> private is not private at all in D, and because of this, 
>> classes are fundamentally broken in D (by design apparently).
>>
>> Now.. I really do have better ways to spend my time. I've made 
>> my point. Nobody who uses D seems to think in a similar way, 
>> apparently, so I leave it at that.
>
> Classes are *not* broken in D. The module is the lowest level 
> of encapsulation and provides exactly what encapsulation is 
> supposed to provide -- the ability to hide the implementation 
> from the outside world so that it may be changed without 
> breaking the API. Being able to access private class members in 
> the same module does not break encapsulation.

Yes, it does.

The first example is unit testing. Having access to the private 
members of a class inside the same module is a mistake because it 
breaks the idea of encapsulation. Unit testing must be done 
exclusively on public members of a class. If you are feeling the 
urge to test a class private thing, there is something wrong with 
your class design. In the parallel world of true OOP which D 
tries to avoid as much as possible there is a saying for that: 
"Everytime you test a private method, a unicorn dies".

The second example is inter-class access of private members if 
you have multiple classes in the same module. The "define a class 
per module" is not a solution in this case because D lacks the 
idea of namespace an it's just ridiculous to have a library with 
1000 different modules just to achieve real class encapsulation.

The third example is pollution of IDE code completion in the same 
module with members which are not meant to be there.