Sealed classes - would you want them in D?

[Jonathan M Davis]

On Saturday, May 12, 2018 08:13:12 KingJoffrey via Digitalmars-d wrote:
> On Saturday, 12 May 2018 at 07:39:04 UTC, Jonathan M Davis wrote:
> > Ultimately, it's a tradeoff, and arguments can be made for and
> > against. But in practice, it works extremely well. You're
> > certainly free to not like this particular design choice, but
> > it's one that most of us have no problem with, and I'd be
> > shocked to ever see it change. So, you can be unhappy about it,
> > but complaining isn't going to change anything. You're either
> > going to have to just learn to live with it or not use D.
> >
> > - Jonathan M Davis
>
> I'm not so much complaining about it, as warning others of it.
>
> D modules do NOT (cannot) respect the encapsulation of the class,
> and therefore, D modules containing classes, can very easily (to
> borrow a phrase from Bertrand Meyer) start to resemble "a chunk
> of Swiss cheese that has been left outside for too long..".
>
> As for using D, this is why I don't really use D for anything
> other than small tasks - where I can happily revert to procedural
> type programming ( C like), and not have to worry about the
> issues of broken class encapsulation - which will almost
> certainly lead to unexpected side-effects, and create whole new
> 'class' of problems that D programmers have to deal with.

Honestly, the only time that I've ever seen problems related to the fact
that private relates to the module and not the struct or class is when
there's a problem with a unit tests due to the fact that it's not restricted
in the same way that user code would be e.g. - if a symbol is accidentally
private, the unit test won't catch that.

I have never seen encapsulation issues where someone accidentally uses some
private piece of a class or struct by accident elsewhere in the module, and
the code therefore ends up with a bug. I'm not about to claim that it's
impossible to make such a mistake, but I've never seen one, and in my
experience, the fact that everything in a module can access everything else
in a module (except that functions can't reach into each other) is a
complete non-issue and if anything makes life simpler, because it completely
negates the need to worry about friends in those cases where you really do
need to reach into the innards of a class or struct within the module.

To many of use, you're making a mountain out a mole hill here. While I can
understand why what D has done with private might be disturbing to someone
when they first come to D, in practice, it's proven to work quite well
without causing unexpected side-effects and stray bugs. Maybe it would be
worse if D didn't encourage unit testing the way that it does (I don't
know), but I can unequivocably say that what D has done with private has
worked wonderfully for me and most of the programmers who use D.

- Jonathan M Davis