Sealed classes - would you want them in D?

[aliak]

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
> On Tuesday, May 15, 2018 04:22:30 Mike Parker via Digitalmars-d 
> wrote:
>> On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
>> > - Object independence
>> > - Do not violate encapsulation
>> > - Respect the interface
>>
>> This is what I don't get from your position. What is 
>> encapsulation? Here's what Wikipedia says [1]:
[...]
>>
>> The class in D *is* encapsulated. The interface *is* 
>> respected. I'm not sure what you mean by object independence.
>>
>>
>> [1]
>> https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
>
> If you really insist on the viewpoint that class encapsulation 
> means that nothing outside of that class can access any of its 
> private members, then what D does definitely breaks 
> encapsulation. But having friends in C++ already provides a way 
> to break that. And having access levels like protected and 
> package break it. Ultimately, a good language provides ways to 
> encapsulate data and control access to the internals of a data 
> type, but there are a variety of ways that that can be 
> achieved, and I don't think that I've ever used a language that 
> strictly enforces that nothing can access the internals of a 
> class. It's just that each language provides different ways for 
> stuff outside the class to access the class' internals.
>
> D happens to have gone with a very liberal approach to 
> encapsulation by essentially making everything inside a module 
> friends of each other. It doesn't break the concept of 
> encapsulation any more than C++'s friend or Java's package 
> attribute do. It's just a much more liberal default, and if 
> you're really insistent that nothing outside of a class has 
> access to the stuff inside a class, then D's choice is likely 
> to be seem terrible. So, in that sense, I can see where he's 
> coming from, but ultimately, I think that it's a very narrow 
> viewpoint about what encapsulation means, and for most of us, 
> experience has shown that D's choice works extremely well in 
> practice.
>
> Either way, as long as you understand how D works with private, 
> you have basically the same level of control as what you get 
> with C++ and friend. It's just that if you _really_ don't want 
> anything else to be a friend, you're forced to stick it in 
> another module. So, ultimately, I think that it's mostly a 
> theoretical debate. Pretty much the worst that happens is you 
> accidentally use a member variable directly instead of using a 
> property function to access it, and that's rarely a big deal. 
> Often, it's even desirable.
>
[...]
>
> - Jonathan M Davis

With one big difference, in that those other languages make you 
explicitly leak object internals, if you want it, and also allow 
you to maintain it, if you want it, whereas D implicitly leaks 
class privates to the module whether you want it or not. So 
private in a class is nonintuitive and does indeed break 
encapsulation. This is why Swift has fileprivate to distinguish 
this case, and for good reason.

So I understand D wants to be liberal, but I also understand the 
value of "encapsulation where I want encapsulation to happen", 
which D doesn't let me do without jumping through extra hoops 
(extracting class to another module with the caveat that you lose 
first-class UFCS enabled function access), and only after I've 
spent hours trying to track a state-related bug because private 
is not scoped at the declaration level.

Cheers
- Ali