Inheritance Often Doesn't Make Sense

Having a debate over inheritance without a consensual definition of OO is gonna lead us nowhere.

The word "OO" has been a selling buzzword for several decades. Which means our best bet in getting a sensible definition is to pick the original one.

This is why we keep bringing up "Kay's OO" (which also is, by the way, Coplien's OO, Reenskaugh's, Dave West's ...)

Depends on your definition on vehicle. For many purposes (e.g. going somewhere) it could be, especially if it also existed.

Subtyping just means "having a taxonomy of things, where we can substitute things lower on the taxonomy -- more concrete, more specialized and so on" with things higher up when wanting less abstraction (and vise versa).

And this is pretty much the case with the world -- Plato's "ideas", scientific taxonomies (e.g. of animals and plants), or RDF and semantic taxonomies, and so on are all based on the same concept.

(That doesn't mean they're perfect descriptions of the world, like our class taxonomies in OOP don't lead to perfect descriptions of most problem domains either).

>What about a vehicle which doesn't have wheels, in a world built around assuming that vehicles have wheels?

That's a problem of definition of what should belong in the class of things we call "vehicle" (and you could have the exact same questions when doing OOP).

As such it's not an argument in whether the real world has or doesn't have subtyping.

To some extent, it's a distinction without a difference - at a semantic level, Java only distinguishes between interfaces and purely abstract base classes because one allows multiple inheritance and the other doesn't, and the separate "inherits" and "implements" keywords flow from there. Other languages (like C# and Kotlin) distinguish between interfaces and overridable classes for the purposes of deciding when to allow multiple inheritance, but use the same syntax and terminology for inheriting from both interfaces and base classes. Still other languages make no structural distinction, but still use the word "interface" to refer to base classes that don't include any implementation, and therefore aren't so susceptible to the diamond inheritance problem. TBH, I think the Java-style treatment is the least conceptually consistent, since it's entirely possible to "inherit" a base class without inheriting a single bit of information, either because everything it declares is abstract or because everything got overridden.

There's a pretty decent coverage of all the grotty details of this concept space, and how different languages treat it, in the beginning of the gang of four book.

abs(x) + abs(y) = 1 is a square of side 1.

x^2 + y^2 = 1 is a circle of radius 1.

But abs(x) = positive sqrt(x^2)

so squares and circles ought to have the same 2D parent, since given the x & y, its just a matter of applying the right transform.

y = ax^2 + bx is a parabola through the origin.

y = bx is a line through the origin.

so lines and parabolas ought to have a common 1D curve as a parent, because a parabola reduces to a line when a=0.

clearly a line shifted by a constant is still a line.

so also, a line rotated clockwise or anti clockwise through say 90 degree is still a line.

so then i take a horizontal line, shift it once and rotate it twice, join these 4 lines and get a square.

so squares ought to be a container type with 4 lines ? or wait, if i collapse the two verticals ie. set the height to 0, then a square is just a straight line with no height, which is absolutely true geometrically, but think about the damage you’d do to your type-theory.

but didn’t we just say lines are just degenerate parabolas. so then we ought to be able to take a square, grab its 4 sides which are lines, transformed each line into a parabola, and tell me what that gives you.

and you haven’t even gotten me started on activation functions. since all logistics are richards curves, a gompertz is just a particular richards. so then a relu should inherit from a gompertz and a swish should be a child of relu and somewhere in here we need the hyperbolic tangent, either as a parent or a child or a sibling or the notorious c++ friend function.

now go ask your friendly neighborhood tensorflow colleague why the activations don’t share a common parent, why lines aren’t parabolas and squares aren’t lines and so in and do forth.