Inheritance Often Doesn't Make Sense
sicpers.info
Inheritance Often Doesn't Make Sense
1–10 of 255 posts
Re: Inheritance Often Doesn't Make Sense
#2This gets off to a bad start:
> There are three different types of inheritance going on.
> 1. Ontological inheritance is about specialisation: this thing is a specific variety of that thing (a [soccer ball] is a sphere and it has this radius)
> 2. Abstract data type inheritance is about substitution: this thing behaves in all the ways that thing does and has this behaviour (this is the Liskov substitution principle)
> A common counterexample to OO inheritance is the relationship between a square and a rectangle. Geometrically, a square is a specialisation of a rectangle: every square is a rectangle, not every rectangle is a square. For all s in Squares, s is a Rectangle and width of s is equal to height of s. As a type, this relationship is reversed: you can use a rectangle everywhere you can use a square (by having a rectangle with the same width and height), but you cannot use a square everywhere you can use a rectangle (for example, you can’t give it a different width and height).
> Notice that this is incompatibility between the inheritance directions of the geometric properties and the abstract data type properties of squares and rectangles; two dimensions which are completely unrelated to each other
By the definitions given at the beginning, where the "abstract data type properties" of an object are its properties as considered by the Liskov substitution principle, this is nonsense.
Compare the definition stated in https://en.wikipedia.org/wiki/Liskov_substitution_principle . Type S is substitutable for type T when, if f(x) is true of all objects x of type T, then f(y) is true of all objects y of type S.
Obviously, according to this definition, any subtype S of type T which satisfies the article's definition 1 will also be Liskov substitutable for T and therefore satisfy the article's definition 2 as well. This is as far from being "unrelated concepts" as you can get; the one requires the other.
The example with Squares and Rectangles doesn't make sense either. If you have code that is set up to handle Rectangles, and you give that code a Square, then the code will handle the Square correctly. This is because Squares are Liskov substitutable for Rectangles... which is because Squares are, platonically, a kind of Rectangle.
It looks like the author wants to ask "if I encounter an interface that processes Rectangles, and I can only construct Squares, can I achieve everything, by using Squares, that someone else could have achieved by using Rectangles?" But that is not the Liskov substitution principle, or any sort of type theory principle. That would be a principle of computational equivalence.
Re: Inheritance Often Doesn't Make Sense
#3Oh, come on. The title submitted to HN is "Inheritance often doesn't make sense"; the actual title of the article is "Why inheritance never made any sense". Are you kidding me?
Do we really need, in 2018, another article continuing this particular religious war? Inheritance is just another tool in the software engineer's toolkit. When you need that tool, use it; when you don't, don't. But taking a position where you say it's never the right tool or, conversely, always the right tool makes you sound ignorant and inexperienced.
Re: Inheritance Often Doesn't Make Sense
#4This article seems to be confused about what abstract data type inheritance is, as exemplified by "As a type, this relationship is reversed: you can use a rectangle everywhere you can use a square (by having a rectangle with the same width and height), but you cannot use a square everywhere you can use a rectangle (for example, you can’t give it a different width and height)."
If an abstract data type X inherits from Y, that means that every X can be used where you can use a Y. You can only use a rectangle where a square is expected if that rectangle happens to be a square. Inversely, you can use a square everywhere you can use a rectangle: if you change the width and height of a rectangle, you turn it into a rectangle with different width and heigth; if you change the width and height of a square, you also turn it into a rectangle with different width and height.
That also means that you can't have mutable values, static types and subtyping in the same language: if you apply a mutating function defined for a supertype on a subtype, you might end up also mutating the type of the mutated value by invalidating invariants of the subtype. It's the same problem that made covariant arrays in Java unsound.
If the type system is sound and expressive enough, ontological inheritance ( this thing is a specific variety of that thing) and abstract data type inheritance (this thing behaves in all the ways that thing does and has this behaviour) should be essentially the same thing.
Re: Inheritance Often Doesn't Make Sense
#5This gets off to a bad start: > There are three different types of inheritance going on. > 1. Ontological inheritance is about specialisation: this thing is a specific variety of that thing (a [soccer ball] is a sphere and it has this radius) > 2. Abstract data type inheritance is about substitution: this thing behaves in all the ways that thing does and has this behaviour (this is the Liskov substitution principle)…
[deleted]
Re: Inheritance Often Doesn't Make Sense
#6This gets off to a bad start: > There are three different types of inheritance going on. > 1. Ontological inheritance is about specialisation: this thing is a specific variety of that thing (a [soccer ball] is a sphere and it has this radius) > 2. Abstract data type inheritance is about substitution: this thing behaves in all the ways that thing does and has this behaviour (this is the Liskov substitution principle)…
> If you have code that is set up to handle Rectangles, and you give that code a Square, then the code will handle the Square correctly.
Hmm...try setting different widths and heights on your square.
Re: Inheritance Often Doesn't Make Sense
#7The programmer's perspective:
The phrase 'object-oriented' means a lot of things. Half are obvious, and the other half are mistakes. - Paul Graham.
Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse. - John Ousterhout Scripting, IEEE Computer, March 1998.
The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. - Joe Armstrong
The artiste's perspective:
Everything tends to make one think that there is little relation between an object and that which represents it. - René Magritte, surrealist
The conceptual purist perspective:
The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages. - Alan Kay
The pedagogical perspective:
CSCI 2100: Unlearning Object-Oriented Programming - Discover how to create and use variables that aren't inside of an object hierarchy. Learn about 'functions,' which are like methods but more generally useful. Prerequisite: Any course that used the term 'abstract base class.' - James Hague
Quotes via http://github.com/globalcitizen/taoup
Re: Inheritance Often Doesn't Make Sense
#8Some languages use polymorphic row types and eschew inheritance
https://brianmckenna.org/blog/row_polymorphism_isnt_subtypin...
https://www.reddit.com/r/types/comments/73lg05/comment/dnt7q...
https://noamlewis.wordpress.com/2015/01/20/introducing-sjs-a...
https://github.com/purescript/documentation/blob/master/lang...
Re: Inheritance Often Doesn't Make Sense
#9A couple of other comments have argued that "ontological inheritance" and "abstract data type inheritance" are actually the same thing:
> This is because Squares are Liskov substitutable for Rectangles... which is because Squares are, platonically, a kind of Rectangle.
> If the type system is sound and expressive enough, ontological inheritance ( this thing is a specific variety of that thing) and abstract data type inheritance (this thing behaves in all the ways that thing does and has this behaviour) should be essentially the same thing.
The difference is that ontology exists in the mind of the programmer, but Liskov substitutability is a property of the program itself. No matter how you model it, a Square is "platonically a kind of" Rectangle. But in order for them to be Liskov substitutable, you have to model them in compatible ways. If my Square class only has a sideLength method, I can't substitute it for a Rectangle.
This simple example may seem silly, but as models get more complex, it becomes harder to make them compatible, even if one modeled class of objects seems like "platonically a kind of" another class. You see this kind of thing all the time in real-world systems. For example, in a UI system, an "OpenGL View" is conceptually a kind of "View", and this relationship is modeled by making OpenGLView a subclass of View. Normal 2D drawing doesn't work in this kind of view, however, so it's not Liskov substitutable.
Re: Inheritance Often Doesn't Make Sense
#10This gets off to a bad start: > There are three different types of inheritance going on. > 1. Ontological inheritance is about specialisation: this thing is a specific variety of that thing (a [soccer ball] is a sphere and it has this radius) > 2. Abstract data type inheritance is about substitution: this thing behaves in all the ways that thing does and has this behaviour (this is the Liskov substitution principle)…
> If you have code that is set up to handle Rectangles, and you give that code a Square, then the code will handle the Square correctly. Hmm...try setting different widths and heights on your square.
Many rectangle APIs, even in OO languages, are immutable, so setting width and length isn’t allowed anyways, all you can do is operate on it to get a new one.
I’ve rarely seen a square subtyped as a rectangle, let alone a mutable one. But I guess it’s possible if the mutable and immutable APIs are divided, so that squares are rectangles in its immutable sense but not in its mutable one.