Does "first-class" imply "dynamic"?

1 view
Skip to first unread message

Sukant Hajra

unread,
Jul 15, 2012, 11:01:25 AM7/15/12
to anatom...@googlegroups.com
The definition this group seems to be circling around is something along the
lines of "first-class polymorphic modules" possibly requiring open recursion.

When I think of objects, I often think of dynamic dispatch, and have a hard
time thinking of an object system without this kind of dynamic nature. Is this
valid?

Does "first-class" invariably lead us to dynamic dispatch? Or are the two less
coupled?

I'm interested in looking at case studies like O'Haskell with respect to this
discussion.

-Sukant

William Cook

unread,
Jul 15, 2012, 5:56:36 PM7/15/12
to anatom...@googlegroups.com
Hi Sukant,

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.

W
--
William Cook
Associate Professor, Computer Science
University of Texas at Austin

Sukant Hajra

unread,
Jul 15, 2012, 10:16:13 PM7/15/12
to anatom...@googlegroups.com
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

Will Cook

unread,
Jul 15, 2012, 11:30:10 PM7/15/12
to anatom...@googlegroups.com
Dynamic dispatch *is* object polymorphism. Non-OO people usually don't know there is a third form.

William Cook
Sent from iPhone
> --
> You received this message because you are subscribed to the Google Groups "Anatomy of Object-Oriented Programming" group.
> To post to this group, send email to anatom...@googlegroups.com.
> To unsubscribe from this group, send email to anatomy-of-O...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/anatomy-of-OO?hl=en.

Sukant Hajra

unread,
Jul 16, 2012, 4:21:28 AM7/16/12
to anatom...@googlegroups.com
Excerpts from Will Cook's message of Sun Jul 15 22:30:10 -0500 2012:
>
> Dynamic dispatch *is* object polymorphism. Non-OO people usually don't know
> there is a third form.

Okay, this makes sense to me then. Since it's probably these very same non-OO
people that need the definition the most (myself included), I think it would be
good to keep "object polymorphism" conjoined as one phrase to avoid confusion
or hair-splitting. And if the two expressions are truly interchangeable, I'd
use the phrase "dynamic dispatch" explicitly to avoid as many misconceptions as
possible. We wouldn't want to have a definition that only makes sense to
people that already know the meaning.

This hair-splitting on my part is only for the one-line summary, which appears
to be where the most sensitivity is needed (especially given the controversy
and confusion to date). I guess what I'm suggesting is that "module" for me
was far less problematic than using "polymorphic" without further
qualification.

-Sukant

Kevlin Henney

unread,
Aug 2, 2012, 6:05:36 AM8/2/12
to anatom...@googlegroups.com, anatom...@googlegroups.com, wc...@cs.utexas.edu
Just coming back to this...


On Sunday, 15 July 2012 22:56:36 UTC+1, William Cook wrote:

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.

How does this compare with a functional system in which functions are first class, but can be late bound and, therefore, dynamically dispatched? For example, I can pass a lambda as an argument to be executed by another function.

Kevlin
Reply all
Reply to author
Forward
0 new messages