You're viewing a comment by fulano and its responses.

fulano Permalink
June 18, 2010, 11:26

The way I see it is that there are two orthogonal axes here: polymorphism kind (ad-hoc vs parametric), and mechanism kind (dynamic vs static).

In parametric polymorphism the code works with an unlimited set of (variable, parametrized) types, and the behaviour is essentially identical for all of those types.

Contrast this with ad-hoc polymorphism, where there is a limited, enumerated set of types which are usable in the context, and the behaviour of the code varies as those types change.

On the other axis, dynamic vs static refers to whether the mechanisms which implement the polymorphism are run-time or compile-times ones.

In C++ this leads us to the following classifications:

Subclassing: dynamic, ad-hoc (NB it's only dynamic in the case of virtual functions)

Templates: static, parametric

Overloading: static, ad-hoc

(Can't think of a built-in, dynamic, parametric polymorphism in C++.)

Introduce template specialization, and you start mixing in ad-hoc features into the parametric polymorphism.

I don't really think that it is meaningful to think of casting as a kind of polymorphism.

Comment Responses

June 18, 2010, 17:10

That's a cool way of viewing it. I hadn't thought about it before. Thanks for sharing this view.

Julien Permalink
June 19, 2010, 00:45

Casting any pointer to void* could be considered a limited form of built-in, dynamic, parametric polymorphism.

By stretching things a bit further, you could even see const_cast and reinterpret_cast as falling into the same category.

fulano Permalink
June 19, 2010, 06:39

Agreed. However,

a) inheritance and virtual functions

b) function overloading

c) templates

are all built-in mechanisms for the *creation* of new polymorphic components in a C++ program. These casts simply *are* polymorphic components: you have no means of extending the set.

You could argue that you can use them (especially the void*) to create new polymorphic components, but then *I* wouldn't call it a built-in mechanism any more (it becomes a Turing-trivial argument).

Still, I appreciate the observation. I hadn't thought of the casts in this light before.

Reply To This Comment

(why do I need your e-mail?)

(Your twitter handle, if you have one.)

Type the word "computer_224": (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.