Sealed classes - would you want them in D?

[KingJoffrey]

On Friday, 11 May 2018 at 09:47:39 UTC, Dukc wrote:
> On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:
>> On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
>>>
>>> `private` is for outside the module. Within the module, 
>>> private is not applied because D wanted to avoid C++'s 
>>> `friend` functions.
>>
>> 'private' is "meant" to be part of the implementation of 'the 
>> class'.
>>
>> Whereas D makes it part of the implementation of 'the module' 
>> ( which is an even higher level of abstraction).
>>
>> This is an abomination!
>>
>> A class should have the capacity to protect its 
>> attributes/methods - even from the module.
>
> You can use D private with Java-like "only for members 
> functions" meaning by putting it alone in it's module, if you 
> want.

Yes. I do know this. But that is essentially.. a hack.

A 'private' declaration should be part of the implementation of 
the class, not the class+module. Some say this is just a 
philosphical difference - I say it's a key design issue for 
structured programming.

A 'class' in D, should really be called a 'companion' (of the 
module), rather than a 'class', cause 'class' cannot truly 
implement it's own abstraction, but instead has its abstraction 
absorbed into the higher abstraction of the module.

So now, in D, to understand the class, you must also understand 
the module.

This is a backwards step in language design, in my opinion - for 
various reasons which are easy to examine further.

When I can contain the class abstraction within the class, then I 
will begin to take D more seriously.

Perhaps this is why some say 'idiomatic' D does not really use 
classes (cause they haven't been implemented correctly anyway, so 
why bother using them).