Inheritance Often Doesn't Make Sense • Hacker News Board

Re: Inheritance Often Doesn't Make Sense

#251

Post by Viliam1234 » Mon, Mar 19, 2018, 8:36 PM UTC

bunderbunder wrote: post #196

eikenberry wrote: post #166

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…

> Java only distinguishes between interfaces and purely abstract base classes because one allows multiple inheritance and the other doesn't

No. This is what former C/C++ programmers coming to Java typically believe (some of them even after spending 10 years coding in Java, because old habits die hard).

interface = interface

abstract base class = implementation

Interface and implementation may seem like "a distinction without a difference", because one is just a list of method headers and the other is a list of method headers with method bodies, but semantically they are the opposite of each other.

Re: Inheritance Often Doesn't Make Sense

#252

Post by Viliam1234 » Mon, Mar 19, 2018, 8:49 PM UTC

ken wrote: post #158

I feel as though the rectangle/square example falls down mostly because of a linguistic trick. Rect->Square could be a perfectly reasonable type hierarchy, as long as you don't allow self-mutation of the very attribute that defines this specialization. But then, mutation tends to wreak havoc on inheritance anyway (e.g., covariance/contravariance) -- and almost everything else. When I take the needle out of my record…

This would be overengineering, but the following six types would solve the problem:

* ImmutableSquare

* ImmutableRectangle

* MutableSquare

* MutableRectangle

* Square

* Rectangle

The "Mutable..." classes are mutable, the "Immutable..." classes are immutable, and the "Square" and "Rectangle" classes mean that you can read the values, but there is no guarantee about either mutability or immutability.

In this system, "ImmutableSquare" and "MutableSquare" are subtypes of "Square"; "ImmutableRectangle" and "MutableRectangle" are subtypes of "Rectangle"; and also "ImmutableSquare" is a subtype of "ImmutableRectangle" (and therefore "Rectangle").

But if you go this way, don't be surprised when you end up with millions of classes.

Re: Inheritance Often Doesn't Make Sense

#253

Post by ken » Tue, Mar 20, 2018, 4:36 PM UTC

Viliam1234 wrote: post #252

ken wrote: post #158

I feel as though the rectangle/square example falls down mostly because of a linguistic trick. Rect->Square could be a perfectly reasonable type hierarchy, as long as you don't allow self-mutation of the very attribute that defines this specialization. But then, mutation tends to wreak havoc on inheritance anyway (e.g., covariance/contravariance) -- and almost everything else. When I take the needle out of my record…

This would be overengineering, but the following six types would solve the problem: * ImmutableSquare * ImmutableRectangle * MutableSquare * MutableRectangle * Square * Rectangle The "Mutable..." classes are mutable, the "Immutable..." classes are immutable, and the "Square" and "Rectangle" classes mean that you can read the values, but there is no guarantee about either mutability or immutability. In this system, "I…

In some languages, there are also (non/)threadsafe variants of mutable classes. As you say, this approach blows up quickly.

If I saw that, I would ask what 'problem' it's trying to solve. Is mutation actually the goal, or simply the means? In languages which don't support general mutation (I'm writing Clojure right now), I really don't miss it at all.

Re: Inheritance Often Doesn't Make Sense

#254

Post by stephen_gareth » Wed, Mar 21, 2018, 7:50 PM UTC

Paul_Dirac wrote: post #247

stephen_gareth wrote: post #241

Earlier quoted context omitted.

In Sean Parent's 'Inheritance is the base class of evil' talk Sean outlines an interesting way to achieve runtime polymorphism without inheriting interfaces in C++. https://www.youtube.com/watch?v=bIhUE5uUFOA

But he uses interface inheritance. You see it at 9:44. Where he creates the concept_t and int_model_t inherits from it.

Indeed. But the original type isn't 'burdened' with the interface. I've used the technique for a simple audio signal processing chain.

Re: Inheritance Often Doesn't Make Sense

#255

Post by PaulStatezny » Thu, Mar 29, 2018, 2:10 PM UTC

geezerjay wrote: post #154

PaulStatezny wrote: post #114

Earlier quoted context omitted.

I really dislike this kind of hand-wavy dismissal of ideas/opinions as “programmer-hipster”. It seems to assume the person in question has no intelligent reason behind their thoughts/opinions. And it dismisses the opinion instead of engaging with it intellectually. And having been on the receiving end, it’s insulting. It feels like being called stupid. It’s fine to disagree with opinions, but when you assume people a…

> It seems to assume the person in question has no intelligent reason behind their thoughts/opinions. If they had, they wouldn't systematically resort to baseless appeals to authority, whose only purpose is to intentionally avoid having to present any semblant of an intelligent reason.

> If they had, they wouldn't systematically resort to baseless appeals to authority, whose only purpose is to intentionally avoid having to present any semblant of an intelligent reason.

This is pretty much what I was talking about. It assumes the worst about someone before hearing them out.

It’s a pretty unreasonable assumption to count every reference to Alan Kay’s quote about OOP as a “baseless appeal to authority”.

Perhaps the person has given a lot of deep thought about the matter, and have reached some reasonable conclusions. If you dismiss the person, you’re just cheating yourself of an opportunity to learn and engage in intelligent conversation. And blindly insulting the person.