Return to Answer

Like S.Lotti said above when it has an clear and unambigous IS-A relationship with its parent. It's just that the explanation he gave you isn't sufficient to answer your question.

Because it implies strong behavioral subtyping which means you can treat all it's subtypes as substitutable, there fore treat them the same, i.e:

// assume Cat, Dog & Bird are subtypes of Animal.
// they just override `speak` without changing call signature
    
const animals = [cat, dog, bird]
    
animals.forEach(animal => animal.speak())

This is Liskov Substitution. It's applicable to both static and dynamic languages because behavioral subtyping cannot be checked by a compiler.

Like S.Lotti said above when it has an clear and unambigous IS-A relationship with its parent. It's just that the explanation he gave you lacks an example:

Because it implies strong behavioral subtyping which means you can treat all it's subtypes as substitutable, therefore you can safely assume you can treat them the same, i.e:

// - assume Cat, Dog & Bird 
//   are subtypes of Animal.
// - they just override `speak` without changing call signature
    
const animals = [cat, dog, bird]
    
animals.forEach(animal => animal.speak())

This is Liskov Substitution. It's applicable to both static and dynamic languages because behavioral subtyping cannot be checked by a compiler.

Why model it as an IS-A relationship? Because it implies strong behavioral subtyping which means you can treat all it's subtypes as substitutable, there fore treat them the same, i.e:

I could have any of those 3 instances be the animal in forEach and it wouldn't produce an error or cause them to speak something incorrectly.

Why model it as an IS-A relationship? 

Because it implies strong behavioral subtyping which means you can treat all it's subtypes as substitutable, there fore treat them the same, i.e:

I could have any of those 3 instances be the animal in forEach and it wouldn't produce an error or cause them to speak something incorrectly. Because I made sure to model the relationships in a way that's safe.

This is Liskov Substitution. T

So if it semantically makes sense, you need all the methods of the parent and also satisfies Liskov then it is a good candidate for strong behavioral subtyping, which can be expressed via an IS-A relationship; although not guaranteed since it's undecideable and therefore applicable to both static & dynamic languages (a compiler can't catch it).

What you're expressing is that the child class must have an is-a relationship with the parent and what you're implying is that type: child is a subset of type: parent, therefore the parent can be substituted with the child without the potential for crashes or incorrect behaviour.

Otherwise it violates the Liskov Principle..

... which means you can't safely assume they can be called like that with a guarantee they would always work correctly.

However that misses one of the major points of OOP, polymorphism; which is the ability to treat all subsets of a type in a uniform method.

I don't think mixins are that much different than composition. AFAIK mixins are usually found in language that don't support multiple inheritance and need to emulate it.

The point is to find a middle ground where the minimal amount of code is duplicated, maximum polymoprhism by having a model with the minimal amount of types & at the same avoid caveats such as this one.

This is Liskov Substitution. It's applicable to both static and dynamic languages because behavioral subtyping cannot be checked by a compiler.

So if it semantically makes sense, you need all the methods of the parent and also satisfies Liskov then it is a good candidate for strong behavioral subtyping, which can be expressed via an IS-A relationship

What you're expressing is that the child class must have an is-a relationship with the parent and what you're implying is that type: child is a subset of type: parent, therefore the parent can be substituted with the child without the potential for crashes or incorrect behaviour.

But that means you lost the ability of treating all subsets of a type in a uniform method. So you have to find the right design that maximizes code reuse and correct & safe type relations.

I think mixins are just a type of than composition, usually found in languages that don't support multiple inheritance and need to emulate it.