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

Steven Schveighoffer schveiguy at yahoo.com
Thu May 17 14:14:28 UTC 2018


On 5/17/18 9:38 AM, KingJoffrey wrote:
> On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer wrote:
>>
>> Essentially, if you put your class you want "sealed" into it's own 
>> module, and then publicly import the module from the API module, you 
>> will get the same effect. This is even easier now with the package 
>> module than it used to be.
> 
> Fair enough. Now no OOP programmer has any need to take at look at D.
>
> I can already do that in other, better known, better supported languages.

D's main draw is not OOP. So if you are here for OOP goodies, then you 
are definitely better off looking elsewhere.

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

>> What private currently does is rational and makes sense. It's not the 
>> same as all other languages, but it is the same as some of them. It's 
>> simply a preference, and D picked something different from what you 
>> like. There are things I would have picked differently than D also, 
>> but not much to be done about those choices at this point.
>>
> 
> The other persepective is also rational, and makes sense.

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

> I believe both perspectives could be accomodated, and at the same time 
> without breaking anything, and without affecting in any way, the way 
> people currently use the module.
> 
> The change would be completely blind to those people, until they choose 
> to opt in to the change.

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

> If D is at the point where change can no longer occured, it's over for D.

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


More information about the Digitalmars-d mailing list