Carl Meyer wrote:
It takes her a couple minutes more to get to the real point, which starts at the slide "inheritance is for specialization, not for sharing code."
I'm not sure there's any content in that statement. In a duck-typed language, sharing code is the *only* reason to use inheritance.
Also, what is "specialisation" anyway? Any time you have two objects with the same interface, and mostly-similar but slightly different behaviours, you could regard one as being a specialisation of the other. Whether they share any code or not is an implementation detail.
I think the real issue is that if you specialise something by inheriting and overriding random methods, you make your class fragile with respect to changes in the base class. If the author of the base class changes something undocumented about the way its methods interact with each other, your class may break.
With pluggable behaviours, there is a well-defined interface between the main class and the classes representing the behaviours, so that sort of thing is much less likely to happen.
You could get the same result with inheritance by designating some methods as "designed to be overridden", and documenting how they interact with the rest of the class. Effectively you are then defining an interface *within* the class and between the class and its subclasses. This is really just another implementation of pluggable behaviours where the plugging mechanism consists of overriding one or more methods.
So to summarise, I would say that the issue here isn't really composition vs. inheritance, but structured vs. ad-hoc behaviour modification.
I wouldn't say that one is always better than the other. Sometimes you need to do things that the author of a class didn't anticipate, and then the ability to override things in an ad-hoc manner is very useful. But I think the speaker is right to point out that doing *everything* that way can lead to a lot of trouble.