But OOP isn't really a type of polymorphism, any more than a Ford Focus is a type of internal combustion engine. You claim that:
> OOP is about (subtype) polymorphism... Everything else is there to support and make it easier to apply this concept.
But if that were true, why does your typically OOP language handle polymorphism so poorly? If your only goal is subtype polymorphism, why not just have multimethods and type inheritance and be done with it? Why bother with encapsulation? Why only have single-dispatch?
I haven't said that OOP is a type of polymorphism, I only said that OOP has a type of polymorphism, that is its most important property and easy to overlook when talking about OOP.
I'm also not saying that you could throw away the rest - thinking in objects has value, having the ability to inherit implementation has value (in certain cases) and so on; so definitely the whole is bigger than the sum of the parts.
The comment I responded to said OOP is a metaphor ... but now you're saying it's like a Ford Focus with a certain type of combustion engine. That's exactly my point - it's easy to overlook what makes it tick.
And you asks questions to which you (probably) know the answer.
Multimethods are sweat, but a bitch to optimize and only useful in certain use-cases - that's why Clojure is backing away from them. Single-dispatch is what you need in 80% of the cases and it can be optimized aggressively ... notice the JVM where most method-calls end up not doing a vtable-lookup (not that you can have a vtable with multimethods).
C++ / Java handle OOP so poorly because these are languages with a static type system that can't blend in with OOP (where method dispatching is done at runtime). But that's what people asked for.