Jon Pretty

I'm coming to the conclusion that "subclassing" should only ever be used to talk about relationships between classes, not between types (or instances). Does applying that constraint remove some ambiguity?

Mmm... I might have assumed the wrong implied flaws when you talked about the negative connotations of inheritance. I assumed inflexible hierarchies (and related issues), but that’s not what you meant, is it?

That is the main thing, along with how it facilitates code which depends on non-contractual details of the inherited implementation which get falsified when someone overrides one of them. Let's call these "insincere invariants".

I'm not sure whether overriding or the default of nonfinality should be more specifically to blame here than inheritance itself, but I was lumping them together as part of the same problem.

Right, and that’s why I reacted - this lumping is correct with mainstream OOP but some flaws are subtyping specific and other inheritance specific. But perhaps I’ve carried this thread on too far, apologies :)

But wait, (don't apologise!), what are the subtyping-specific flaws? Did you mean subclassing-specific?

No, I meant subtyping specific. For example, rigid hierarchies - if you have an A and you need a B, and A is not a subtype of B, you’re going some fairly involved ceremonies to make things fit. That’s subtyping. The diamond problem is inheritance specific.

Subclassing, being both, suffers from both problems.