|[19 earlier articles]|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-10-31)|
|Re: Polymorphism vs. Overloading email@example.com (1994-10-31)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (Martin Odersky) (1994-10-31)|
|Re: Polymorphism vs. Overloading email@example.com (1994-10-27)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-10-28)|
|Re: Polymorphism vs. Overloading email@example.com (1994-10-28)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-10-29)|
|Re: Polymorphism vs. Overloading email@example.com (1994-10-29)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-11-01)|
|Re: Polymorphism vs. Overloading email@example.com (kanze) (1994-11-01)|
|Re: Polymorphism vs. Overloading davidm@Rational.COM (1994-10-31)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-11-01)|
|Re: Polymorphism vs. Overloading email@example.com (1994-11-01)|
|[5 later articles]|
|From:||firstname.lastname@example.org (Mike Mc Gaughey)|
|Organization:||Computer Science, Monash University, Australia|
|Date:||Sat, 29 Oct 1994 03:48:44 GMT|
email@example.com (Mike Ryer) writes:
>Overloading happens at compilation time -- the compiler decides which function
>to invoke based on statically-determined types of the operands.
>Polymorphism may not happen until runtime -- the compiler generates code that
>fans out based on the runtime value of a tag.
Wow - three posts all claiming polymorphism happens at runtime :)
Overloading was identified (by Strachey?) as `ad-hoc polymorphism'; the
idea was that if functions of the same name could exhibit very different
behaviours at different argument types, they were overloaded. The obvious
example is `+' applied to integer or real arguments - they require different
He also identified `parametric polymorphism' as the class of functions
whose behaviour is specified in some uniform way over some class of
objects (eg: lists of <anything>); other people (eg. Cardelli) have
called this `generic polymorphism'. The basic requirement here is
that although the types of *some* parts of the objects provided as
parameters may be unknown, the function in question doesn't need to
examine those parts of an object to operate correctly (that's why
it doesn't care about their types).
There is no requirement for tags to support this at runtime in a
strongly statically typed language; all that is required is that the
generated code be capable of processing the elements of all types that
satisfy the assumptions of the given set of types.
Two common examples of this: object oriented languages with single
inheritance can simply lay out the inherited (supertype) part of the
object as a prefix to the rest of the object. Polymorphic functional
languages can (and do!) rely on the assumption that all polymorphic
items are just pointers to the heap, and hence have the same size and
copying semantics (which is sufficient, assuming you don't have a
`polymorphic' equality operator). Modulo some current difficulties
with garbage collection, this allows them to be implemented without
tags. In fact, until recently it was *overloading* in functional
languages which used the tags; parametrically polymorphic functions
never examine type tags on data.
In C++, all `polymorphism' is actually treated as overloading - and is
compiled that way, by generating seperate concrete code sequences for the
different instances of templated classes, and resolving the actual
calls at link time.
Thus, the precise time at which `type resolution' happens is very much
an implementation issue; the meaning of `polymorphic' really *includes*
overloading as a subclass.
Mike McGaughey AARNET: firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.