Content deleted Content added
''ad hoc'' |
|||
Line 1:
{{Polymorphism}}
In [[programming languages]], '''''ad hoc'' polymorphism'''<ref>C. Strachey, Fundamental concepts in programming languages. Lecture notes for International Summer School in Computer Programming, Copenhagen, August 1967</ref> is a kind of [[polymorphism (computer science)|polymorphism]] in which polymorphic functions can be applied to arguments of different types, because a polymorphic function can denote a number of distinct and potentially heterogeneous implementations depending on the type of argument(s) to which it is applied. It is also known as [[function overloading]] or [[operator overloading]]. The term
==
''Ad hoc'' polymorphism is a [[
This type of polymorphism is common in [[object-oriented programming]] languages, many of which allow [[operator (programming)|operator]]s to be overloaded in a manner similar to functions (see [[operator overloading]]). Some languages that are not dynamically typed and lack ''ad hoc'' polymorphism (including type classes) have longer function names such as <code>print_int</code>, <code>print_string</code>, etc. This can be seen as advantage (more descriptive) or a disadvantage (overly verbose) depending on one's point of view.
An advantage that is sometimes gained from overloading is the appearance of specialization, e.g., a function with the same name can be implemented in multiple different ways, each optimized for the particular data types that it operates on. This can provide a convenient interface for code that needs to be specialized to multiple situations for performance reasons. The downside is that the type system cannot guarantee the consistency of the different implementations.
Line 12:
Since overloading is done at compile time, it is not a substitute for [[late binding]] as found in [[subtyping polymorphism]].
==
The previous section notwithstanding, there are other ways in which ''ad hoc'' polymorphism can work out. Consider for example the Smalltalk language. In [[Smalltalk]], the overloading is done at run time, as the methods ("function implementation") for each overloaded message ("overloaded function") are resolved when they are about to be executed. This happens at run time, after the program is compiled. Therefore, polymorphism is given by [[subtyping polymorphism]] as in other languages, and it is also extended in functionality by ''ad hoc'' polymorphism at run time.▼
A closer look will also reveal that Smalltalk provides a slightly different variety of ''ad hoc'' polymorphism. Since Smalltalk has a late bound execution model, and since it provides objects the ability to handle messages that are not understood, it is possible to go ahead and implement functionality using polymorphism without explicitly overloading a particular message. This may not be generally recommended practice for everyday programming, but it can be quite useful when implementing proxies.▼
▲The previous section notwithstanding, there are other ways in which ad hoc polymorphism can work out. Consider for example the Smalltalk language. In [[Smalltalk]], the overloading is done at run time, as the methods ("function implementation") for each overloaded message ("overloaded function") are resolved when they are about to be executed. This happens at run time, after the program is compiled. Therefore, polymorphism is given by [[subtyping polymorphism]] as in other languages, and it is also extended in functionality by ad hoc polymorphism at run time.
▲A closer look will also reveal that Smalltalk provides a slightly different variety of ad hoc polymorphism. Since Smalltalk has a late bound execution model, and since it provides objects the ability to handle messages that are not understood, it is possible to go ahead and implement functionality using polymorphism without explicitly overloading a particular message. This may not be generally recommended practice for everyday programming, but it can be quite useful when implementing proxies.
Also, while in general terms common class method and constructor overloading is not considered polymorphism, there are more uniform languages in which classes are regular objects. In Smalltalk, for instance, classes are regular objects. In turn, this means messages sent to classes can be overloaded, and it is also possible to create objects that behave like classes without their classes inheriting from the hierarchy of classes. These are effective techniques which can be used to take advantage of Smalltalk's powerful reflection capabilities. Similar arrangements are also possible in languages such as [[Self (programming language)|Self]] and Newspeak.
==Example==
Imagine an operator <code>+</code> that may be used in the following ways:
# <code>1 + 2 = 3</code>
Line 39 ⟶ 37:
(Note that string types used in the last case do not, by themselves, lend themselves to the programmer ''naturally'' assuming concatenation, rather than addition, is meant; consider "123" + "456", which might reasonably be expected to yield "579". Overloading can therefore provide different meaning, or semantics, for an operation, as well as differing implementations.)
==
{{reflist}}
|