Pointer Cast Polymorphism
- ) Use of downcasts in order to achieve generic polymorphism in a language which only supports subtype polymorphism. Java code is full of this; though JDK1.5 (as well as its research predecessors like PizzaLanguage) will mostly fix this problem for Java. This sort of PointerCastPolymorphism is usually typesafe; however it requires a lot of runtime type checks, and it ain't no fun to write code this way. (Many C++ programmers do this too with, preferring DynamicCast rather than templates, on the (questionable) grounds that they will reduce code bloat in this manner.)
- ) Use of void * (or similar constructs) coupled with pointers-to-functions (or tables of pointers-to-functions--an ersatz VeeTable) to achieve ANY sort of polymorphism (both generic and subtype) in a language which has none at all; CeeLanguage being an example. The C library qsort() function is a fine example of this. How many of us have implemented in C a generic algorithm with a qsort()-style interface, or come up with a pseudo-object framework to give C programmers the equivalent of subtype polymorphism and virtual functions? Unlike the first case above; this type of PointerCastPolymorphism is usually type-UNSAFE (unless the programmer adds typechecks him/herself), and quite fragile. Ugh.
It's worth pointing out that Gnome, one of the two major GUIs for Linux (and other Unices), is chock full of #2. (It's the only modern GUI I'm aware of that is implemented primarily in a non-OO language.) The surprising thing is that it usually works quite well...
GObject, the C-language object system used in Gnome, Gtk and other libraries, implements its own runtime type checking system, so is really of type #1.
Perhaps; though doing typechecking in a bunch of macros isn't as neat and clean as doing it in the language proper. Writing code for GObject is truly ugly....--ScottJohnson
Bah, PointerCastPolymorphism is one of those things like ExplicitMemoryManagement: easy to do wrong, causes programming overhead, ugly (if one is used to something better), but works just fine when the programmer knows what e's doing and chooses a universal set of rules. It's easy enough to do e.g. ComponentObjectModel programming in C; Flux OsKit does that quite neatly.
For more examples of PointerCastPolymorphism, simply look to any of the older OpenSource programming languages. Most of them implement polymorphism, and themselves are implemented in CeeLanguage, and so as such are chock full of manual refcounting, manual polymorphism, and various other features. PythonLanguage is a particularly good example of this to look at, since it's system is designed to be easily extended by users for the purpose making custom Python types in CeeLanguage (a tricky, but not painful, process).
See also PointerMetaprogramming and some discussion on FirstClass.