Newsgroups: comp.lang.smalltalk,comp.object
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!swrinde!howland.reston.ans.net!ix.netcom.com!netcom.com!milod
From: milod@netcom.com (John DiCamillo)
Subject: Re: Polymorphism One More Time
Message-ID: <milodDo6LCM.371@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <NEWTNews.13339.826235188.hampton@interramp.com> <3145C961.501F@amd.com>
Date: Wed, 13 Mar 1996 00:57:57 GMT
Lines: 109
Sender: milod@netcom16.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:35919 comp.object:45755

"Paul G. Schaaf, Jr." <paul.schaaf@amd.com> writes:
>us011245@interramp.com wrote:
>> I have been reading the comments on my (admittedly) simplified explanation of
>> polymorphism with interest because they illustrate my point.  The (extended)
>> definition given in response to my example of a polymorphic function is a
>> variation on the definition offered by Booch in Object Oriented Analysis and
>> Design, 2nd Edition, page 517.     

>Excuse the theory here, but clarifications are in order.

They certainly are.

>   MY DEFINITION (as posted earlier in this thread):
>   Given a system of interacting objects, polymorphism is the ability to replace 
>   some object in that system with any other object provided that the new object 
>   implements the same interface as its predecessor.  By "implements the same 
>   interface", I mean the subset of that object's full interface that is 
>   excercised when the object is in that system.  A fully polymorphic system is 
>   one for which this is true for every object in that system.  

This sounds more like the Liskov Substitutability Principle than
a definition of polymorphism.  And in any event, why are you
trying to define a word that already has a generally accepted
definition?  Do you wish to be understood or is this just wordplay?

>   BOOCH'S DEFINITION:
>   A concept in type theory, according to which a name (such as a variable 
>   declaration) may denote objects of many different classes that are related by 
>   some common superclass; thus, any object denoted by this name is able to 
>   respond to some common set of operations in different ways.  

This isn't really "Booch's Definition" (is it?) it seems to be
more his rephrasing someone else's definition.

In any case, the term polymorphism goes back at least as far as
Strachey's "Fundamental Concepts in Programming Languages", 1967.
The generally accepted modern definition is presented in Cardelli
& Wegner "On Understanding Types, Data Abstraction, and Polymorphism"
1985, which can be found at:

http://www.research.digital.com/SRC/personal/Luca_Cardelli/Papers.html

That paper defines four different kinds of polymorphism, of which
Smalltalk appears to directly support two*: Inclusion and Overloading.
Inclusion polymorphism is the kind most people mean when they use
the word - sending a message to an object known through a base type
reference, and having it execute a method in a sub type.  Overloading
is a form of ad hoc polymorphism in which operations work (or seem
to work) on arguments (including self) of several different types.

*That is, one or two, depending on whether you believe Smalltalk
has types.

>> This definition comes from Type Theory, and, IMHO, explains virtually nothing 
>> in the context of object oriented programming.

Well, I don't think Booch phrased the definition very well either,
but I find the Cardelli & Wegner paper quite informative. YMMV.

>>   That was precisely the reason for my crack about flames from theoreticians.

Well, I'm not one, and this isn't.

[snip]

>Also, if one understands the fundamentals of OO, one is in a better position to 
>see what Smalltalk, for instance, has to offer over c++ for a particular task.  

Garsh, I wonder what the "fundamentals of OO" might be, and how they
might differentiate Smalltalk from C++?

>> My point is not that the other definitions are wrong, far from it.  They are 
>> in some context, in this case type theory, much more correct than mine;
>> however, in attempting to be so precise these explanations completely obscure
>> the meaning in the context of object oriented methodology and programming.

Oh, not really.  It may seem that way in regard to Smalltalk, a
language in which type does not play a powerful role, but under-
standing these concepts in terms of basic type theory is quite
helpful when working with more richly typed languages.  (Yes, I
realize this thread started in a strictly Smalltalk forum, but
I don't understand why anyone would choose *not* to learn some-
thing from other OO programming languages.)

>> This makes what we're doing sound incomprehensible and inaccessible to the
>> "layprogrammer".  I think explanations should clarify, not mistify.

>   A noble goal.  Any attempt of clarification must also depend upon one's
>definition of "layprogrammer".  
>   A person with very little or no programming experience would not understand 
>what the "big deal" is with polymorphism;

This, at least, I can agree with.

>after all, software is _supposed to_ 
>reflect the real world, something which polymorphism enables.  

Uh, no.  To a person with no programming experience, software
is _supposed to_ provide solutions to problems.  How it gets
that job done (e.g. by "reflect[ing] the real world") is a
matter of very little concern.

[misc. ignorant comparisons between Smalltalk and C++ deleted]

-- 
    ciao,
    milo
================================================================
    John DiCamillo                         Fiery the Angels Fell 
    milod@netcom.com       Deep thunder rode around their shores
