[imtringued]

People are overthinking this.

In practice inheritance is a very special case of composition that is only advantageous in a very narrow set of usecases. Basically almost never.

In fact the number of usecases is so low that I would prefer that modern languages just omit it entirely because the added value is incredibly tiny compared to the cost of confused developers.

The primary difference between an interface and inheritance is that with inheritance you do not have to implement every method and can use the default implementation of the base class.

Example:

    class Piece {
        int x
        int y
        boolean validMove(int newX, int newY) {
            return false;     
        }
    }

    class Queen extends Piece {
        boolean validMove(int newX, int newY)
        //we use the default implementation
    }

Is equivalent to this

    interface IPiece {
         boolean validMove(int newX, int newY);
    }

    class Piece() implements IPiece {
        int x
        int y
        boolean validMove(int newX, int newY) {
            return false;     
        }
    }

    class Queen implements IPiece {
        Piece piece;
        boolean validMove(int newX, int newY) {
            //we use the default implementation
            return piece.validMove(newX, newY);
        }
    }

Inheritance doesn't actually offer any code reuse. All it does is choose the default implementation of the parent class. If you have dozens of polymorphic functions in a class and only want to change 3 it might be convenient. I would question why you need so much polymorphism to warrant a special language feature. C and Rust developers are fine without it. Functional programmers are fine without it. But for some reason in OOP you need it everywhere and are actually worse off because it's overused.

Modern language designers, please do not implement inheritance of classes in your new languages!

[hota_mazi]

> In practice inheritance is a very special case of composition that is only advantageous in a very narrow set of usecases.

You are confused. See my other message below where I show that composition and inheritance are not mutually exclusive (and arguably, the best of both worlds is using inheritance via composition).

[mikekchar]

Edit: Sigh... This message is badly written, mainly because I confused your point :-) I'm not quite sure why I was thinking you were arguing that it was not an ISA relationship. In any case, removing my addled brain from the equation is probably useful -- you can probably figure out that there is more than one way to look at this. And while you clearly think that your way is correct, it is useful to view it from other perspectives.

While it is interesting to see your viewpoint, you may also consider that not everybody will see it the same way that you do. For example, why do you suppose that inheritance via composition makes it not an ISA relationship? Is a Swiss Army knife a screwdriver? You may say "no", but others may say "yes" -- it is a screwdriver by way of containing a screwdriver. You can verify this usage of the language simply by listening to sales pitches for the crap they sell on the shopping channel :-) ISA and HASA do not necessarily need to be exclusive properties.

It's easy to get wrapped up in your own definitions of things and to block out how others may view the universe. This is precisely why I originally asked the question. I appreciated the enlightenment. I hope that the above will help you achieve the same.

[hota_mazi]

> For example, why do you suppose that inheritance via composition makes it not an ISA relationship?

I don't. My other message [1] clearly states:

    class A(b: B) : B by b // IS_A via composition

My point is that inheritance can be achieved in many different ways, composition being one of them.

Inheritance is an architecture concept, composition is a mechanism which can be used to implement inheritance. They are complementary.

[1] https://news.ycombinator.com/item?id=16050458