Runtime Polymorphism

RunTime polymorphism is a form of PolyMorphism (see PolymorphismExample) at which FunctionBinding? occurs at runtime. This means that the exact function that is bound to need not be known at CompileTime.

Typically, runtime polymorphism is implemented in ObjectOrientedProgramming by requiring the programmer to define BaseClasses or InterfaceClass?es that contain at least the FunctionSignature?s of one or more ClassMethod?s. Interfaces are analogous to AbstractClasses in languages that do not differentiate between interface classes and "real" classes, e.g., CeePlusPlus.

A function can then accept an ObjectPointer or ObjectReference? of the base class or interface and call its methods as if they were monomorphic methods. Code that uses the function can instantiate a DerivedClass? and pass a reference of the new object to this function, and the calls to the base class methods will be properly dispatched to the derived class. Usually, the compiler forbids the instantiation of a class that does not provide FunctionDefinition?s for all inherited method signatures, where method definitions aren't also inherited as well. In some languages, like JavaLanguage and CeeSharp, the compiler is even stricter and requires that all real classes must implement all method signatures obtained from DirectInheritance? of interface classes, while interface classes must never provide method definitions, and cannot be instantiated.

Some languages, for example PerlLanguage, do not use any kind of StaticTypeChecking? for runtime polymorphism. In these languages, trying to call a method for which no suitable definition is found will result in a RuntimeError?. Other examples are SmalltalkLanguage, RubyLanguage, and ObjectiveCee.

LispLanguage, in turn, does not use the ObjectMetaphor? at all and permits polymorphism in more than one parameter (the object reference in object-oriented languages counts as a parameter), called MultiMethods.

Runtime polymorphism is often interchangeable with CompiletimePolymorphism?. Runtime polymorphism can be substituted almost anywhere that compile time polymorphism is employed, though the converse is not true. On the other hand, in situations where compile time polymorphism can be used, it is often regarded as superior because of more thorough StaticTypeChecking?, higher efficiency, and/or higher convenience (in particular, to avoid having to use a lot of DownCast?s).