Unless the term 'generic programming' is older than I'm aware of, the word 'polymorphism' has been a technical term in programming language research longer than 'generic programming'. Certainly the word polymorphism has been in use longer than the language C++ has existed. Inheritance polymorphism / class polymorphism is one means of implementing polymorphism. It does cause a moment of confusion the first time you see the word used in a more general sense if you are used to thinking of polymorphism only referring to one kind of polymorphism.

Forgive my lack of C++ knowledge, but surely inheritance is a separate topic to polymophism?

If we think of a classic OOP example, we might say (in some made-up language):

    Mammals can breathe
    Mammals can move

    Dogs are Mammals
    Dolphins are Mammals

From this, we know that Dogs and Dolphins can breathe and move, so we can write code like:

    function checkStatus(Mammal m) {
      try {
        m.move();
        return "Free";
      } catch {
        try {
          m.breathe();
          return "Trapped";
        } catch {
          return "Dead";
        }
      }
    }

This code is subclass polymorphic, since we can pass in a Dog or a Dolphin, or some other type of Mammal, and it will work unchanged.

Yet this is completely orthogonal to inheritance! There are two ways we might actually implement these constructs:

- Mammal is an interface: Dog implements breathe by operating its lungs and move by operating its legs; Dolphin implements breathe by operating its lungs and move by operating its tail and fins.

- Mammal is an abstract class which implements breathe by operating its lungs. Dog inherits breathe and implements move by operating its legs; Dolphin inherits breathe and implements move by operating its tail and fins.

Both of these are valid approaches, but consider that:

- Only the second approach uses inheritance, so it seems strange to limit "polymorphism" to only this case.

- The checkStatus code doesn't actually care which approach we take. It's "polymorphic in our choice of polymorphism"!

Also, let's say that we did restrict the term "polymorphism" to these sorts of mechanisms. We might say that the above example is "polymorphic in the choice of Mammal". In which case, the "stage polymorphism" of this article is nothing other than "polymorphic in the choice of stage".

We could implement it in a language like C++ something like:

    Stages can call functions with arguments
    Stages can branch on booleans
    ...

    Interpreter is a Stage
    Compiler is a Stage

We achieve polymophism by passing around the currentStage, and writing code like `currentStage.call(myFunc, myArg)`. If `currentStage` is an `Interpreter`, the call will be performed immediately. If `currentStage` is a `Compiler`, code will be generated to perform the call.

The only difference between such an OO setup and the actual implementation in the article is that boilerplate like `currentStage` is all handled implicitly, rather than manually passed around, and we overload the normal language constructs rather than replacing them with methods, e.g. we can write `double(foo)` instead of `currentStage.call(double, foo)`, and `if foo then bar else baz` instead of `currentStage.branch(foo, bar, baz)` (or something even worse, to ensure that `bar` and `baz` get delayed!)

C++ supports multiple kinds of polymorphism depending on if and how they can be implemented with no or low runtime overhead. C++ does tend to conflate class inheritance with interface polymorphism, but there is an implementation reason for doing so.

In C++, an image of the data members of a base class is embedded verbatim inside a derived object. This means that a function compiled to work with a pointer to a block of memory formatted as a Base object can just as well be passed a pointer to the region of memory corresponding to a Base object inside the larger block of memory allocated to a Derived object. So C++ saying that inheritance implies polymorphism is not because they are conceptually the same, but rather that an implementation exists that can give both features at once for little runtime overhead.

Also, C++ doesn't distinguish between interfaces and classes; an interface in C++ is just a class with no data members.

Runtime polymorphism in C++ requires marking methods as virtual. They are not virtual by default. Why not? Because the default assumption is that code can operate directly (and efficiently) on what it statically knows about an object, and in the case when none of the methods are virtual it allows the object and code to be slimmed down slightly.

C++ has many other forms of polymorphism, method overloading or operator overloading (a.k.a. ad hoc polymorphism), templates, etc. The reason they are not all treated as the same is because their implementations are different. Hiding all of the differences would impose a small but fixed cost on all of them, which would be counter to C++'s principle of you don't pay for what you don't use.

Thanks for the info. I'm not sure if it's supporting my point, refuting it, or is an aside :)

> Also, C++ doesn't distinguish between interfaces and classes; an interface in C++ is just a class with no data members.

This doesn't invalidate the point about polymorphism being orthogonal to inheritance. The point is that we can choose whether or not to use inheritance: `breathe` could be implemented in `Mammal` and get inherited by `Dog` and `Dolphin`, or Dog and Dolphin could implement `breathe` themselves and there would be no inheritance. Either way, we still have (subclass) polymorphism, so saying "polymorphism should mean inheritance" seems like a bad idea.

This might help..... or it might add further to the confusion -- http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orla...