[hota_mazi]

It seems nuts to me that anyone would expect the Queen class to extend Bishop just because they happen to move diagonally. A Queen "IS NOT A" Bishop.

If anything, specify traits that define the movement of the pieces and have each piece extend that trait (with the Queen extending both CAN_MOVE_DIAGONALLY and CAN_MOVE_LATERALLY).

[qznc]

Yes. A similar way to argue is Liskov's substitution principle [0]. It is easy to come up with properties that always hold for bishops, but not for queens. For example, bishops never move from black to white fields or vice versa.

[0] https://en.wikipedia.org/wiki/Liskov_substitution_principle

[wbkang]

It is reasonable for implementation re-use (subclassing) but it flunks the subtyping aspect.

[jgalt212]

composition over inheritance

https://en.wikipedia.org/wiki/Composition_over_inheritance

[hota_mazi]

No, my observation has nothing to do with composition vs/ inheritance.

It's about defining what a class IS vs/ what a class HAS.

[mikekchar]

It's hard to ask this question without sounding snarky, but I hope you will understand that I'm seriously curious to hear what you think.

> No, my observation has nothing to do with composition vs/ inheritance.

> It's about defining what a class IS vs/ what a class HAS.

What do you feel is the difference between these two sentences? In other words, why is inheritance vs composition not the same as what a class is vs what a class has?

[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]

These concepts are orthogonal.

I can use composition and inheritance to define an IS_A relationship and I can use them to define a HAS_A relationship.

For example, in Kotlin:

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

[eiffel31]

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

I couldn't find the "B by b" syntax from the Kotlin docs, can you tell me that this does ?

[hota_mazi]

It's delegation.

Look at page 96 of this PDF file: https://kotlinlang.org/docs/kotlin-docs.pdf