Indeed. Polymorphism does not imply a weakly typed language. Compare:
This is an Objective-C method which takes a Parameter of type id (the equivalent of a Java Object) and runs the "dance" method of the object.
This will compile and work, even though there is no guarantee that the aParameter object implements the dance method. If it doesn't, you will receive a runtime error. Compare this with the equivalent* Java code:
This will get a compile-time error because Object does not have a dance method. If you defined an abstract class Dancer** which had a dance method, you could change the parameter type to Dancer and everything would be copacetic. But the key is that Dancer would have to have the abstract method defined or else it would be in the same boat as Object in the above example--a compile-time error.
Lesson learned:
It's the compile-time type of a variable that defines what an object can do, but the run-time type that determines how it does it. --------
* OK, the actual equivalent code would be:
but that's from an implementation point of view, not a coder's point of view
----------
** Actually, Dancer would best be served as an interface instead of an abstract class. That way, if you had a Human Class, a Bumblebee class, and a Warthog class (each of which inherited from the abstract Animal class), your Human and bumblebee class could implement the Dancer interface since both of them can dance, while the Warthog would be unable to dance. (At least, I've never seen a dancing warthog
) You could then pass both Humans and Bumblebees to the above method, since both of them are Dancers.
[ May 14, 2003: Message edited by: Joel McNary ]