Sealed classes - would you want them in D?

[Mike Parker]

On Friday, 11 May 2018 at 19:45:10 UTC, rumbu wrote:

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

My point is that it *doesn't* break encapsulation. The *module* 
is the lowest level of encapsulation, not the class. The public 
API is not affected by any changes internal to the module. And, 
like Jonathan, I disagree with the assertion that private members 
shouldn't be tested.

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

Again, they're in the same module. From an encapsulation stand 
point, what does it matter that private members are within or 
without any specific set of curly braces? It only matters if you 
want to adhere to a purely conceptual view of encapsulation. From 
a practical view, it matters not one whit.

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

If they're in the same module, then they're meant to be there.