Live data from Hacker News

Inheritance Often Doesn't Make Sense

sicpers.info

211–220 of 255 posts

Re: Inheritance Often Doesn't Make Sense

#211

Earlier quoted context omitted.

In the language of the article, this is subtyping without subclassing. Sure Java/C# implement this as interfaces, but in C++ this would be a case of multiple inheritance. This is a good example of the article's main point that people mean a lot of different things by inheritance and get different value from the different applications of the concept.

There are at least a few ways to define and implement interfaces in C++ without touching inheritance.

Structures of function pointers and, what, string method names? My C++ is rusty, but that's all I can think of. I guess there's a lot of variations on structures of pointers...

Re: Inheritance Often Doesn't Make Sense

#212

Earlier quoted context omitted.

In the language of the article, this is subtyping without subclassing. Sure Java/C# implement this as interfaces, but in C++ this would be a case of multiple inheritance. This is a good example of the article's main point that people mean a lot of different things by inheritance and get different value from the different applications of the concept.

There are at least a few ways to define and implement interfaces in C++ without touching inheritance.

Could you name a few? I was under the impression that inheritance was the only way.

Re: Inheritance Often Doesn't Make Sense

#213

Earlier quoted context omitted.

The distinction between "implementing" an interface and "inheriting" a base class is largely just a Java-ism. 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…

I kind of like interfaces as they are basically less powerful traits. I think there is a big difference to class inheritance and the difference between e.g. Jave and C# is just syntactic. When you implement interfaces you have to explicitly implement all methods. If you implement them correctly all methods using them continue to stay correct (including C# extension methods or java interface default methods). With cla…

[deleted]

Re: Inheritance Often Doesn't Make Sense

#214
post #9

A 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…

The thing is, rectangles are a kind of square, and squares are a kind of rectangle, from different perspectives.

From what perspective is a rectangle a kind of square?

Re: Inheritance Often Doesn't Make Sense

#215
post #206

Earlier quoted context omitted.

Can you give a mechanical example of inheritance, so we can see the difference?

I think the term “interface” is used in many related but different ways in software, but I think the most obvious mechanical analogy would be basically anything that uses a common “plug” or “adapter.” Like a vacuum cleaner with different attachments. Or even HDMI for video/audio.

You're confusing inheritance with implementing an interface. I'm not sure there is an example in the real world, because the real world is concerned with function, not taxonomy. It hardly makes sense to say "cordless drill inherits from screw driver"; rather, they both implement the "drives screw" interface. Ontological inheritance really doesn't make any sense at all for modeling systems (sometimes ontologies are useful as data in a system, but probably never for modeling the system itself).

Re: Inheritance Often Doesn't Make Sense

#216
post #20

> you cannot use a square everywhere you can use a rectangle (for example, you can’t give it a different width and height) Can someone come up with a better example here? Intuitively, I would say, "Yes, if you ask me for any rectangle, and you reject a square, you are wrong." If you say you can use any rectangle to do your thing, you should absolutely be able to also use a square. Why am I not convinced with the give…

> Yes, if you ask me for any rectangle, and you reject a square, you are wrong

Intuitively it makes sense, but practically... What if your function wants to set the width and the height to different values?

This is valid for a rectangle, not for a square.

From a mathematical perspective, a square might be a rectangle. From a software standpoint, it's not.

The reason for the discrepancy between mathematics and programming?

Mutability.

Re: Inheritance Often Doesn't Make Sense

#217

Earlier quoted context omitted.

What you are describing is an interface, not inheritance. They are implementing an pulley interface, not inheriting a specific pulley implementation from a common housing or something.

The distinction between "implementing" an interface and "inheriting" a base class is largely just a Java-ism. 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…

Interfaces are a distinct concept from inheritance. Inheritance can be used as an interface mechanism, but that's merely an implementation detail. For example, Go has interfaces with no inheritance at all. It's unfortunate that most people think of Java or C# interfaces by default; it really creates a lot of confusion.

Re: Inheritance Often Doesn't Make Sense

#218
post #9

A 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…

> but as models get more complex, it becomes harder to make them compatible

One thing that helps, is locally-scoped facades, like ruby's refinements.[1] You don't need complete model substitutability, only locally-sufficient substitutability.

[1] https://ruby-doc.org/core-2.5.0/doc/syntax/refinements_rdoc....

Re: Inheritance Often Doesn't Make Sense

#219
post #206

Earlier quoted context omitted.

I think the term “interface” is used in many related but different ways in software, but I think the most obvious mechanical analogy would be basically anything that uses a common “plug” or “adapter.” Like a vacuum cleaner with different attachments. Or even HDMI for video/audio.

You're confusing inheritance with implementing an interface. I'm not sure there is an example in the real world, because the real world is concerned with function, not taxonomy. It hardly makes sense to say "cordless drill inherits from screw driver"; rather, they both implement the "drives screw" interface. Ontological inheritance really doesn't make any sense at all for modeling systems (sometimes ontologies are us…

I’m not confusing those things. I’m giving an example of an interface, as requested.

Re: Inheritance Often Doesn't Make Sense

#220

Earlier quoted context omitted.

The thing is, rectangles are a kind of square, and squares are a kind of rectangle, from different perspectives.

From what perspective is a rectangle a kind of square?

From a write-only perspective. If you imagine mutating operations that square might have (for example setSideLength) rectangles can satisfy them perfectly well.
Post reply on HN