Jon Pretty

But subclass inheritance implies subtyping, doesn’t it? I agree that inheritance and subtyping are distinct concepts, but if you consider that only subclass inheritance exists, how is it distinct from subtyping?

Subtyping concerns a superset relationship on the set of provable properties of a type (e.g. method signatures), and inheritance concerns the sharing of the runtime implementations of none, some, most or all those properties, and is conferred (only, I thought...) by subclassing.

Here’s my current understanding: subtyping is telling you “A is a B”, inheritance “A has access to a known subset of B’s code”. I believe modules can inherit from one another and they’re not classes, the same argument goes for typeclasses.

There is, of course, clearly an ancestor / descendant relationship, but it needs not be semantic - subclassing mixes the two, at least in languages like scala and java, but it’s not a necessity. C++ has inheritance without subtyping, java subtyping without inheritance

/rant

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".