Sealed classes - would you want them in D?

[KingJoffrey]

On Saturday, 12 May 2018 at 13:38:18 UTC, Walter Bright wrote:
>
> Mike's right. D's encapsulation model is designed around the 
> module.

Actually, that is not true. If it were true, then I could do:

------------
module test;
void main() { i = 2; }  // sorry, but i belongs to another unit 
of encapsulation
void foo() { int i = 1; }
------------

D only breaks the encapsulation properties of classes, not 
functions.

Since the vast majority of programmers use classes as the basis 
for encapsulation, this surely presents a significant problem to 
those coming over to D, rightly expecting that encapsulation to 
be retained.

> If a module is too large to be comprehended, it should be 
> broken up into smaller modules, each with its encapsulated 
> functionality.

But that's why we have functions and classes - which are their 
own level of smaller units of encapsulation. Blurring the 
boundary of encapsulation seems like a big step backward in terms 
of structured programming.

Each unit of code (a function, a class, a module) should respect 
the encapsulation properties of each other.

There's simply no point in using classes in D, as they have no 
capacity to encapsulate themselves (whereas function still retain 
this privilege)

Now if 'private' meant 'private to the class' (as most people 
would rightly expect), and the default if you had no attribute 
was, say, 'accessible to the module', then I could probably live 
with that, and I would start to use classes in D productively.

But when the class has lost its capacity to encapsulate, it's 
lost its purpose.

It is hard enough to hold a class in working memory so you can 
reason about.

Making us hold whole modules in memory so we can reason about the 
interaction between classes and modules, is just nonsense, in my 
opinion.