Newsgroups: comp.lang.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: Co-ordinating the polymorphism in C++
Message-ID: <1991Feb13.011731.10114@gpu.utcs.utoronto.ca>
Organization: UTCS Public Access
References: <1991Feb11.003849.27340@gpu.utcs.utoronto.ca> <600@taumet.com>
Date: Wed, 13 Feb 1991 01:17:31 GMT


>craig writes:
>|Now that C++ has three polymorphism mechanisms
>|	- overloading		(compile-time)
>|	- templates		(link-time)
>|	- virtual functions	(run-time)
>
>Overloading need have no relation to polymorphism.

Overloading *is* a form of polymorphism, albeit a static one.  I can 
write three functions that accept three different kinds of argument,
and tell the user it is one function accepting any of the three. In
fact, that is exactly what I *should* tell the user.  The fact that
this can be reconciled at compile-time, and could in theory be looked
up by the programmer who could in theory "know" the exact function
called is irrelevant.  The fact that this does not require the creation 
of a run-time table is just an optimization.

This is no different that building three types that inherit the same
virtual function.  So far as the user who simply uses the type is
concerned, these approaches are identical.  The difference comes when
you try to extend the type family.  But in both cases, you will write
a new function to deal with a new case.

If what you are trying to say is that you can overload without using
virtuals, that's true.  If you're trying to say that a user of a type
family needs to think of them as different things, I disagree.  In
fact it is pretty common to provide the same kind of functions through 
overloading and virtuals.  Imagine an exponent function for ints, vs.
one for complex numbers, vs. one for rationals.  The user-defined types
may be part of a matrix of number types, while the C-like types are not.
Two mechanisms, one result.  One could make a similar point about friend
vs. member functions, but that is only a data hiding issue.  It doesn't
much affect external behavior.

>Templates and polymorphism are orthogonal concepts.

Templates are closely related to inheritance in that they are both
ways to create a family of types with similar behavior.  In fact,
templates produce a family of types with *identical* behavior but
a slightly different implementation and compatibility with a different
set of types (e.g. a list of people vs. a list of shapes).

"Orthogonal" in the sense that they can be implemented separately, but
not in terms of how they interact to the user.  Imagine I create a template
"list", and I create a list of "employee".  Now I create a list of "manager".
If "manager" is a subclass of "employee", should "list of manager" be a
subclass of "list of employee" ?  There would be few problems in using a
list of pointers to managers where a list of pointers to employees was
expected.  Could the lists have some other relationship?

Polymorphism can be defined many ways:  from the compiler's point of
view, viewing every substitution of one hunk of bits for another as if it
might require a compatibility check or a conversion.  from the *producing*
programmer's point of view, viewing these substitutions in terms of the
different mechanisms that need to be invoked to make this work, or from
the *consuming* programmers' point of view, in terms of the consistency
of behavior of the types and operations in a library or application.

What I am suggesting, is that C++ may need some mechanism that makes it
easier to look at things from the consuming programmer's point of view.
Otherwise, C++ will be a language of code "producers" like C rather than
any kind of revolution in programming.

The ideas for assertions that have been raised in the group are one idea.
These can serve as partial contracts of behavior, and some might be shared by
many operations that implement their "consistent" behavior in different ways.
Or perhaps such assertions are better left for CASE tools to provide.
That's why I'm raising the question.

>Steve Clamage, TauMetric Corp, steve@taumet.com

  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
  28 First Avenue, Toronto, Ontario M4M 1W8 Canada     Voice: (416) 466-4097


-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
