Sealed classes - would you want them in D?

[Jonathan M Davis]

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]:
>
> "Encapsulation is used to hide the values or state of a
> structured data object inside a class, preventing unauthorized
> parties' direct access to them. Publicly accessible methods are
> generally provided in the class (so-called getters and setters)
> to access the values, and other client classes call these methods
> to retrieve and modify the values within the object."
>
> This has been my understanding of encapsulation since I first
> learned of it years ago. How is this broken in D? Only if you
> insist on viewing it in a strictly theoretical sense. As a matter
> of practical reality, it is not broken.
>
> If you have access to the internals of the class, you also have
> access to the rest of the module. No client of the class outside
> of the module has any access to the implementation. I showed you
> an example earlier of how silly it would be to force the rest of
> the module to use some sort of "module private" interface.
>
> 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.

Regardless, I think that it's quite clear that we're not going to convince
KingJoffrey of anything, and it's unlikely that he's going to convince us -
though honestly, with that username, I have to wonder if he's complaining
about this issue to just screw around with us for fun. But even if he's
completely serious, I think that it's clear that at best we're going to
agree to disagree.

- Jonathan M Davis