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.


Reply via email to