Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!mintaka!spdcc!esegue!compilers-sender From: norman@a.cs.okstate.edu Newsgroups: comp.compilers Subject: Re: Polymorphism vs. overloading Keywords: polymorphism Message-ID: <1990Sep14.033933.5276@esegue.segue.boston.ma.us> Date: 12 Sep 90 16:12:53 GMT References: <9009100341.AA17336@m.cs.uiuc.edu> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: norman@a.cs.okstate.edu Organization: Compilers Central Lines: 114 Approved: compilers@esegue.segue.boston.ma.us >From article <9009100341.AA17336@m.cs.uiuc.edu>, by johnson@cs.uiuc.edu (Ralph J ohnson): > 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 them.) > "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 types. 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: norman@a.cs.okstate.edu Computing and Information Sciences BangPath: 219 Mathematical Sciences Building {cbosgd,rutgers}!okstate!norman Stillwater, OK USA 74078-0599 -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.