Sealed classes - would you want them in D? (v2)

[KingJoffrey]

On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
> On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
>> I propose an idea, for discussion (robust discussion even 
>> better ;-)
>>
>> Add an new attribute to class, named 'sealed'.
>
> If class level protection is added, please do not call it 
> sealed.
> People from c++ might be suprised by 'private' already. We do 
> not have to confuse those c#ies too.

Interesting.

If only D had applied that same criteria to use of the word 
'private'.

I do wonder what word could possibly suffice, to please everyone.


> Module level protection is enough to hide implementation 
> details though. So while i do understand why you want this in 
> D, i don't think it is worth it to complicate the language for 
> something you can work around easily by putting the classes in 
> their own modules.

Here, I think you are falling into the trap, of believing, that 
the concept of
modularity can only ever apply the way D currently applies it - 
at the file level.

In OOP programming, the class is the module. (yes, I know how 
much D programmers love OOP ;-)

When OOP programmers come to D however, they are 'forced' into 
the D concept of modularity, and cannot model modularity in 
accordance with their own problem domain - but have no choice to 
use one class per file - just to regain what they already have in 
other mainstream languages. But then, for those OOP programmer, 
the 'file' has little value, cause it now can only ever represent 
a single class.

Remember, that the idea here is not to force anyone to change how 
they currently think or do things. It simply extends the way in 
which a 'file' module can be used.


> I'm also not convinced think that your 'sealed' would be used 
> much, because accessing private state in the module is actually 
> extremly useful (e.g. unittests).
>

Again, what people can do, they will still be able to do. Nothing 
changes for them.

btw. D has less than 1000 programmers. How many OOP programmers 
in the world?
Build it, and they will come...perhaps.

> That beeing said, if you are convinced it would be a good 
> addition, please write a DIP.

DIP before discussion, is not the way I do things.

> Even if it will not be accepted it will at least force a 
> decision. And we can point to the reasons it got 
> accepted/rejected in the future.

Again, DIP before discussion, and we all know what will happed to 
the DIP.