Re: Defining polymorphism vs. overloading (James C Burley)
1 Sep 90 01:31:13

          From comp.compilers

Related articles
Defining polymorphism vs. overloading (1990-08-30)
Re: Defining polymorphism vs. overloading (1990-09-01)
Re: Defining polymorphism vs. overloading (1990-09-02)
Re: Defining polymorphism vs. overloading (1990-09-03)
Re: Defining polymorphism vs. overloading (1990-09-03)
Re: Defining polymorphism vs. overloading (1990-09-03)
Re: Defining polymorphism vs. overloading (1990-09-03)
Re: Defining polymorphism vs. overloading (1990-09-03)
[15 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: (James C Burley)
In-Reply-To:'s message of 31 Aug 90 04:19:43 GMT
Keywords: polymorphism, design
Organization: The World
References: <>
Date: 1 Sep 90 01:31:13

In article <> (Oliver Sharp) writes:

          o Overloading means using the same name (or symbol) to invoke different
              code depending on the types of the arguments (or operands)....

          o Polymorphism means using the same piece of code to operate on objects of
              different types. In LISP, cons is polymorphic because you can give it
              arguments of different types but it goes ahead and does its thing without
              worrying about it.

      Well, that seems pretty straight-forward so far, but in practice the
      distinction isn't so clean. For example, think about square braces in C.
      I've heard people say that they are overloaded, because they can apply to
      arrays of different types ... but, by our just agreed on definitions, they
      are really polymorphic. I'd look at someone funny if they said "braces are
      polymorphic in C", though, wouldn't you? I've also heard people describe
      things that are clearly overloaded as being polymorphic.

                                                        ...I'm really curious. What do YOU think the
      distinction is? Or isn't there one? Do you use these terms consistently?

      - Oliver Sharp

It seems to me you kind of made the distinction already in your bullet items,
except when you talked about LISP (and as a LISP-ignorant, I can't be sure
about that, either).

Overloading means using the same operation to "invoke different code", you
say, and polymorphism uses the same "piece of code to operate on objects of
different types".

Conceptually, what is the difference? Let's look at our favorite overloaded
operator, addition:

        y + z

Now if y and z can be of several valid types, we say that + is overloaded
because we know it must perform different actions depending on the types.

Now let's look at a function:


Here, if y and z can be of several valid types, we say that foo is polymorphic.

But this isn't quite right either: in fact, if you maintain a consistent view
of what the phrase "of several valid types" means in the above two examples,
then the outcome changes. For example, let's take the view that it means "of
several valid types, but the particular type for each y and z is known at the
time when the operation is recognized" (compile time). In that case, we'd
view both "y + z" and "foo(y,z)" as cases of overloaded operations.

On the other hand, let's say that it means "of several valid types, and the
particular type for each y and z is not determined until the point at which
the operation is to be performed" (i.e. run-time). In that case, I think it
is clear that not only would we view "foo(y,z)" as indeed polymorphic, but
"y + z" also, because we'd recognize that either the machine code would have
to be embedded in a separate function, making "y + z" the same as saying
"add(y,z)" where add is that separate function, or the machine hardware would
itself make the determination when performing its ADD operation, making the
operation polymorphic.

So it appears that a person-on-the-street description of the difference between
"overloaded" and "polymorphic" depends on assuming an environment where
recognizing (i.e. interpreting or compiling) a program is an activity distinct
from, and a necessary prelude to, performing (i.e. running) that program.

I'm sure that to academics, this is an inadequate description, but it makes
sense to me for now. I view LISP as primarily an interpreted language where
type information is carried around along with "variables", so that's why I
think LISP is kind of out of place here: I'd guess that in LISP, the only
places where overloading and polymorphism are different have to do with
performing compilation tasks or things like macro handling and such.

Square brackets in C++ therefore strike me as overloaded, and possibly
polymorphic: overloaded because foo[3] results in an operation that depends
(at compile time) on the size (thus the type) of foo (so a single
implementation involving a particular size is chosen for placement in the
program being created); possibly polymorphic because objA[objB] can result
(via overloading) in calling a function that takes objA and objB as arguments,
but which is implemented so that the actual types of the arguments may be
classA and classB or their subclasses -- the same function code is run
(in most implementations, anyway) even if the types are classK and classY.

I'd disagree that square brackets in C, however, are polymorphic: a given
piece of code using square brackets executes the same code each time it is
run, because when it is compiled, the types of its operands is known. You
can't write a function in C that expects an int array, uses [] to access
elements of that array, then at run time pass it a char array and expect it
to make the adjustment -- it'll treat the char array as an int array.

Another way of looking at it: overloading teaches a compiler's symbol table
management some new tricks, but code generation is not usually much different.
Polymorphism teaches a compiler's code generation (and run-time library) some
new tricks, but symbol table management is not much different.

Like my guess about LISP, my recollection of Smalltalk is that it makes no
distinction between overloading and polymorphism, as it is an interpreted
language. (Well, they "compile", but it means something different to them
than it would to a C++ programmer...and of course real Smalltalk compilers
are probably available, but to the extent they don't change the language
itself, I think the lack of distinction remains.)

James Craig Burley, Software Craftsperson

Post a followup to this message

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