Sealed classes - would you want them in D?

[Jonathan M Davis]

On Friday, May 11, 2018 19:45:10 rumbu via Digitalmars-d wrote:
> On Friday, 11 May 2018 at 16:51:30 UTC, Mike Parker wrote:
> > On Friday, 11 May 2018 at 14:05:25 UTC, KingJoffrey wrote:
> >> private is not private at all in D, and because of this,
> >> classes are fundamentally broken in D (by design apparently).
> >>
> >> Now.. I really do have better ways to spend my time. I've made
> >> my point. Nobody who uses D seems to think in a similar way,
> >> apparently, so I leave it at that.
> >
> > Classes are *not* broken in D. The module is the lowest level
> > of encapsulation and provides exactly what encapsulation is
> > supposed to provide -- the ability to hide the implementation
> > from the outside world so that it may be changed without
> > breaking the API. Being able to access private class members in
> > the same module does not break encapsulation.
>
> Yes, it does.
>
> The first example is unit testing. Having access to the private
> members of a class inside the same module is a mistake because it
> breaks the idea of encapsulation. Unit testing must be done
> exclusively on public members of a class. If you are feeling the
> urge to test a class private thing, there is something wrong with
> your class design. In the parallel world of true OOP which D
> tries to avoid as much as possible there is a saying for that:
> "Everytime you test a private method, a unicorn dies".

I completely disagree with this. Testing private functions can be extremely
valuable for ensuring that everything within the type functions the way that
it should and can often lead to much better testing of how pieces of a type
work, because you have better control over what's going on at that exact
point in the call chain when you're testing it directly. I don't see how the
access level of a function has anything to do with whether it makes sense to
test it beyond the fact that it's more important that public functions be
tested, because that's what users are going to be calling. But well-tested
private functions help ensure that public functions work correctly,
especially when a private function is used by multiple public functions -
just like you want the functions that you're calling from other modules to
work correctly even though they're not part of the public API of this type
or module. I do not understand how anyone could argue that testing private
functions is a bad idea.

- Jonathan M Davis