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

KingJoffrey KingJoffrey at KingJoffrey.com
Fri May 18 02:08:47 UTC 2018


On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer 
wrote:
>
> D's main draw is not OOP. So if you are here for OOP goodies, 
> then you are definitely better off looking elsewhere.
>

I'll add that too my list of D forum quotes.

> That being said, D does have OOP, and many OOP programmers are 
> fine with the current state of affairs.

How many OOP programmers in the world?

How many of them use D?

Your use of the word 'many' is questionable.

>
> Not disputing that, it's a reasonable choice either way.

And yet, the D community is intent on not empowering the 
programmer to make that choice themselves.


>
> Unfortunately, that fails the first time you see code that has 
> "sealed" on it, and have to go figure out what exactly that 
> means.

That's what happend to me, with the 'D version' of 'private'.

You can say the same for every other attribute D has, that I had 
never seen before.

It's a nonsense argument that many use, to prevent change.


>
> That's not what was stated. This proposal is a convenience 
> feature, because you can already accomplish what is requested 
> (making sure private internals are inaccessible to certain 
> parts of the code). At this point, making incremental changes 
> like this requires a very high bar of acceptance since you 
> would be adding another complication to a language that is 
> fairly stable. If I were you, I would stop worrying about this 
> and either accept the status quo or look for a language that 
> suits your requirements more directly. I think there are 
> probably no people here who think D is the "perfect language", 
> or that there even exists a "perfect language", you just have 
> to judge whether the warts are worth living with or not.
>
> You're welcome to write a DIP, but I don't see a very good 
> chance for acceptance given the discussions on this subject.
>
> -Steve

I agree. The D community is too small, and insufficiently diverse 
to discuss this any further.

It's funny how we build programming languages to serve us, but we 
end up serving them.



More information about the Digitalmars-d mailing list