Re: Polymorphism vs. overloading
Wed, 12 Sep 90 11:12:53 CDT

          From comp.compilers

Related articles
Polymorphism vs. overloading (Ralph Johnson) (1990-09-09)
Re: Polymorphism vs. overloading (1990-09-12)
Re: Polymorphism vs. overloading (1990-09-14)
Polymorphism vs. Overloading (1994-10-22)
Re: Polymorphism vs. Overloading (1994-10-22)
Polymorphism vs. Overloading (1994-10-27)
Re: Polymorphism vs. Overloading (1994-10-24)
Re: Polymorphism vs. Overloading (1994-10-28)
[29 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
Keywords: polymorphism
Organization: Compilers Central
References: <>
Date: Wed, 12 Sep 90 11:12:53 CDT

>From article <>, by (Ralph J
> I don't like any of the definitions that I have seen so far.
> Instead of just being rude, I'll give my own.

What's wrong with using the standard definitions as they occur in the
literature? Has no one bothered to read Cardelli and Wegner's excellent
article on this topic? [1] And how about Danforth and Tomlinson's article on
types and OOP? [2] Surely we owe some consideration to Strachey, the first
person to distinguish between 'parametric' and 'ad-hoc' polymorphism. [3]
(I'll sketch Cardelli and Wegner's definitions at the end of this article
for those of you who don't want to read the articles. But please read the
articles: They provide much more than definitions and I'm sure you'll enjoy

> "Polymorphic" refers to a procedure definition. [...]

That's not quite correct. Any entity that can have a type can also have a
polymorphic type: This includes variables, constants, functions, modules,
etc. Don't fall into the trap of limiting a concept merely because some
language does not provide a complete implementation of that concept.

> Overloading (in Ada and C++, at least) means that there are several
> different procedure definitions that define procedures with the same
> names, but with different argument types (or, in the case of Ada,
> result types). The compiler figures out which one to call based on
> the types of the arguments (or, in Ada, expected return type). This
> has nothing to do with any kind of polymorphism.

Au contraire (see below).

> Most of the answers seem to imply that the late-binding in
> object-oriented programming is a form of overloading. This is
> not true, since overloading means something that can be handled
> by the compiler. In fact, late-binding can be considered to be
> normal polymorphism, i.e. a procedure that can take arguments of
> many different types.
> [Example omitted]
> I like to call this distinguishing characteristic of object-oriented
> languages "polymorphism implemented by late-binding of procedure
> calls". It is not very short, but it is accurate. There are other
> ways to achieve polymorphism, but this is the kind that gives
> object-oriented programming its power.

You're correct--late binding in oop is not a form of overloading; but
your definition of overloading seems to be amiss. Also, the polymorphism
in object-oriented languages has already been described in the literature,
so you needn't give it a new name.

Cardelli and Wegner describe the polymorphism hierarchy as follows:

    [Since most people seem to be interested only in polymorphic
    functions, I'll play along and give the definitions in terms
    of functions. Feel free to extend these definitions to included
    other values in your language of choice.]

        1) Polymorphism

                  1.1) Universal Polymorphism--normally, functions that work on
                                an infinite number of types, with all types sharing
                                some common structure.

                                1.1.1) Parametric Polymorphism--obtained when a function
                                                  works uniformly on a range of types that normally
                                                  exhibit some common structure. In this type of
                                                  polymorphism, the function has an implicit or
                                                  explicit type parameter that determines the
                                                  type of the argument for each application of
                                                  that function. These functions are also called
                                                  generic functions.

                                1.1.2) Inclusion Polymorphism--objects can be viewed as
                                                  belonging to many different classes that need
                                                  not be disjoint (i.e. there may be an inclusion
                                                  of classes).

                  1.2) Ad-hoc Polymorphism--exhibited by functions that operate
                                on a finite set of different and potentially unrelated

                                1.2.1) Overloading--the same name is used to denote
                                                  different functions and _context_ is used to
                                                  decide which particular function is denoted
                                                  by an instance of that name. This is just
                                                  a convenient syntactic abbreviation as each
                                                  function could be given a unique name.

                                1.2.2) Coercion--a semantic operation that converts
                                                  an argument to the type expected by a function.
                                                  Coercions are used to prevent type errors.
                                                  Coercions may be provided at compile time or
                                                  they may be provided at run-time via tests on
                                                  the arguments.

[1] L. Cardelli and P. Wegner, "On understanding types, data abstraction,
        and polymorphism," Computing Surveys, Vol. 17, No. 4, December 1985,
        pp. 471-522.

[2] S. Danforth and C. Tomlinson, "Type theories and object-oriented
        programming," Computing Surveys, Vol. 20, No. 1, March 1988, pp. 29-72.

[3] C. Strachey, "Fundamental concepts in programming languages," Lecture
        notes for International Summer School in Computer Programming,
        Copenhagen, August 1967.
Norman Graham Oklahoma State University
    Internet: Computing and Information Sciences
    BangPath: 219 Mathematical Sciences Building
          {cbosgd,rutgers}!okstate!norman Stillwater, OK USA 74078-0599

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.