Excerpts from William Cook's message of Sun Jul 15 16:56:36 -0500 2012:
>
> polymorphic = dynamic dispatch. This is essential
>
> But first-class doesn't imply dynamic dispatch. Imagine a C++ class that did
> NOT use virtual methods. The objects would be first-class but not dynamically
> dispatched. This is similar to the situation with values that are instances
> of Haskell type classes.
This is a bit of what I feared. So "first-class" doesn't imply dynamic
dispatch. But I'm not sure "polymorphic" does either (I'm happy to be
corrected on this).
Polymorhism seems as though it's been expressed in far too many ways beyond
dynamic dispatch. Right now, I'm thinking of ad hoc polymorphism and
parametric polymorphism. The term to me is far too overloaded to be practical
without further assistance. And as you pointed out in your blog post, the
etymology of the term isn't terribly exact either (many forms).
On Twitter, I caught the following comment:
... his new definition sounds like "Abstract Data Type" to me.
I empathize with this sentiment. The new definition may well be too vague
relative to the clarity of the "On Understanding Data Abstraction, Revisited"
essay, which makes pretty clear the difference between objects and ADTs. The
essay doesn't clearly define objects (from what I can tell). Rather, it seems
to rely more on a comparative study between objects and ADTs. Still, though, I
would hate to see the clarity of the essay lost with a new vocabulary that's
too vague.
If dynamic dispatch is really essential, then what's the harm of calling it out
by name? It may avoid confusion. The only problem I could see is missing the
essence of object-orientation by inadvertently excluding an object system we'd
prefer to have included.
-Sukant