Jon Pretty

I’m trying very hard to not jump in and say that actually, you’re not talking about inheritance but subclassing- one implies the other, but they’re not the same. Clearly I failed.

I think I never considered anything other than subclass inheritance to be inheritance... though I've been encouraging careful distinction between subtyping and inheritance for years...

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?