Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inheritance was invented as a performance hack

catern.com

Post reply on HN
Print view View original

71–80 of 268 posts

Re: Inheritance was invented as a performance hack

#71

Post by catlifeonmars »

username90 wrote: post #53
foo_barrio wrote: post #41

Earlier quoted context omitted.

There is no state to track. If there is, 99% composition has worked out way better for me in the long run since I don't have this really strong coupling between two objects.

So you don't have a need for code reuse then since you don't have many types with the same base structure, just say that instead of saying that it is bad.

There are often more straightforward ways to reuse code than to use inheritance. ~Two~ three advantages of composition for code reuse:

1. Composition is often more explicit than inheritance. Inheritance is overly magic.

2. Composition avoids incidental coupling of methods. With inheritance this is unavoidable.

3. Composition is more difficult to misuse. Both composition and inheritance have their purposes. In the wild, I’ve seen inheritance misapplied much more often than I have seen with composition.

Re: Inheritance was invented as a performance hack

#72

Post by [deleted] »

thewickedaxe wrote: post #19

I'm a little confused. Inheritance, types and all that stuff are just language concepts right? Simula may have been one of the first to implement inheritance as a means to an end, but how could they have "invented" inheritance? I'm sure the idea of inheritance was already there in language proofs. [I might be really really wrong here]

[deleted]

Re: Inheritance was invented as a performance hack

#73

Post by rectang »

hota_mazi wrote: post #45
bradrobertson wrote: post #7

Earlier quoted context omitted.

"Catching on" doesn't mean "is the right way to do things". Code reuse is in fact a prime example of a misuse of inheritance

It's the main reason why inheritance became so popular and so useful. Specialization remains a very common design pattern that is incredibly useful and trivially and intuitively solved with inheritance. No other programming concept (HKT, ad hoc polymorphism, functional programming, etc...) comes close to its elegance.

> Specialization remains a very common design pattern that is incredibly useful and trivially and intuitively solved with inheritance.

Beautifully put. That matches up with my own experience learning classical OOP, even if I'm now comfortable with other models.

Re: Inheritance was invented as a performance hack

#75

Post by saiojd »

valenterry wrote: post #47

After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…

Thank you, this is exactly it. The problem with inheritance is specifically overloading, and not anything else. Composition as it is being used currently has its own drawbacks (need to manually delegate every method, no clear model for instance construction, the need to duplicate fields across classes, etc.). I wish overloading was just removed from inheritance or that composition had better language support.

Re: Inheritance was invented as a performance hack

#76

Post by fiddlerwoaroof »

zeckalpha wrote: post #74
fiddlerwoaroof wrote: post #30

Earlier quoted context omitted.

It turned write-only before the Eternal September of wikispam set in

Write-only is a great place for spam... no need to read it!

Oops, I’m going to leave it because it’s funny.

Re: Inheritance was invented as a performance hack

#77

Post by valenterry »

valenterry wrote: post #47

After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…

I am being downvoted and I would really like to hear from people why that is - e.g. if I said something that is not correct, please point it out so that I can learn from it.

Re: Inheritance was invented as a performance hack

#78

Post by judofyr »

valenterry wrote: post #47

After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…

> This problem is impossible to fix and it is a general problem - when overwriting a method, you can never be sure that semantics could break when the base class is changed.

I'm not sure what's so special about overwriting methods here. There are many cases where semantics can break as a dependency changes. One example would be whether a callback is executed on the same thread (or event-loop tick) or in the background. A function might assume that the callback should be pure and thus in a later version switch where it's being executed. If your code depended on it being executed in a certain way, then it'll now be broken. The problem here is that there were certain constraints of the function which you weren't aware of (possibly because it wasn't documented).

A base class will have a similar constraints that you, as a subclasser, must be aware of.

Your stack example is also a good example of where inheritance is actually useful:

    class CountingStack(...) extends Stack {
       override def push(element) returns nothing =
           count += 1; super.push(element)
       
       override def pop() returns element =
           count -= 1; super.pop(element)
    }
Assuming that the Stack class specifies that all modifications will go through the push and pop methods, this ensures that the count is maintained regardless of how many other utility methods that exists on Stack (i.e. clear()). You don't have to extend the CountingStack with extra methods as the Stack methods gain more methods.

Re: Inheritance was invented as a performance hack

#79

Post by nathias »

username90 wrote: post #64
thewickedaxe wrote: post #19

I'm a little confused. Inheritance, types and all that stuff are just language concepts right? Simula may have been one of the first to implement inheritance as a means to an end, but how could they have "invented" inheritance? I'm sure the idea of inheritance was already there in language proofs. [I might be really really wrong here]

Theory usually comes after practice. People create something that works, then theorists formalizes it into a well defined concept.

idea > practice > formalization or idea > formalization > practice
Post reply on HN