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: <milodDo831M.J5F@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <NEWTNews.13339.826235188.hampton@interramp.com> <3145C961.501F@amd.com> <milodDo6LCM.371@netcom.com> <3146E905.2F45@concentric.net>
Date: Wed, 13 Mar 1996 20:17:45 GMT
Lines: 166
Sender: milod@netcom16.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:35958 comp.object:45826

"Alan L. Lovejoy" <alovejoy@concentric.net> writes:
>John DiCamillo wrote:
>> "Paul G. Schaaf, Jr." <paul.schaaf@amd.com> writes:

>>> [Schaaf's definition elided]

>> 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?

>Can you not see that the substitutability principle and the
>ability to apply the 
>same function (name) to "many types" of argument (receiver)
>are deeply related?

Of course they are deeply related; that does not imply they are
_the same_.  It seems to me that the use of polymorphism results
in substitutablity, but that does not make substitutability a
satisfying operational definition of polymorphism.

>A definition of polymorphism should not just be programming
>language independent, but computer science independent.
>It is a very abstract concept, best defined
>(IMHO) by denotational semantics.

I'm sorry, you've lost me here. "Computer science independent"?


>> The generally accepted modern definition is presented in Cardelli
>> & Wegner "On Understanding Types, Data Abstraction, and Polymorphism".
>> 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.

>To quote Cardelli (from the same web page you mentioned):

>	"Polymorphic" means to have "many forms". As related to programming
>   languages, it refers to data or programs that have many types, or that
>   operate on many types.

OK, that's a good general definition that I can live with. Although
I find the full description more useful.

>So a Collection that can hold "many types" of element, or a function
>(name) that can be applied to "many types" of arguments are examples
>of polymorphism--in accord with Cardelli's definition.

They are examples of polymorphic programs and data, yes.

>Abstractly, polymorphism results from the unification of the denotational
>semantics of the components of a system.  Full polymorphism obtains when
>everything in the system is a first class object, when objects are not
>semantically segregated into denotational discontinuities (e.g., instances
>of "traditional/simple types" vs. instances of "classes" in C++).

>Smalltalk is polymorphic because "everything is an object," because you
>can assign any object to any slot (variable or message parameter), because
>you can send any message to any object, because you can return any object
>from any function (method), and because even the metaobjects are "first
>class" objects.

(Properly speaking, in Smalltalk "all values are objects".  Methods
are not objects, or weren't when I programmed in Smalltalk.)

>Properly speaking, things like "inclusion" and "overloading" are mechanisms
>or devices that are agonists for polymorphism.  Polymorphism is a property,
>not a device!

>Reference: "Polymorphic Programming Languages" [Harland]

OK.  I might not have phrased it quite that way, but I can live with it.

>> >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++?

>I think the implication is that polymorphism is the raison d'etre of OO.

Hmmn.  I don't quite agree with that.  Reusability and maintainability
are the motivations for OOPLs, as is improved modeling of the application
domain.  Polymorphism is a powerful tool for achieving these goals, as
you state below.

>That is, one designs a language with OO constructs (objects that
>encapsulate state and behavior, messages that dynamically dispatch methods
>(functions), inheritance and/or delegation, and classes (optional)) because
>such OO mechanisms are powerful and proven devices for giving the language
>and the programs written in it the property of polymorphism.

>And if you want to know why polymorphism is a desirable property, compare the
>collection classes of C++ to those of Smalltalk.  Polymorphism enhances the
>ability to code abstractly and design reusable algorithms, components,
>frameworks and architectures.  Smalltalk has a significantly greater portion
>of the polymorhpism property, as the example of the Collection classes aptly
>demonstrates.

I claim that much of the usefulness of the Smalltalk collection classes
obtains from the use of higher-order functions, and would be present in
a statically typed OO language that also posessed higher-order functions.
Obviously, that will have to remain an unproven claim, as there do not
appear to be any statically typed OOPLs with higher-order functions.

>Static typing is the antithesis of OO, because it inhibits polymorphism.
>This is the lesson the Java designers have yet to learn (and they aren't
>the only ones).

And this is where we will have to disagree.  Static typing does indeed
constrain polymorphism (I don't agree with the connotations of "inhibit"),
but this does not make it the antithesis of OO.  Why?  Because static
typing does not constrain polymorphism to the point where significant
reuse is prohibited.

>> >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.

>I don't think Paul was concerned with what a novice may think the
>purpose of "software" is.  More importantly, it is clear from the
>context that by "software" he means "the working parts of a 
>software program."  A program that does not faithfully model the
>problem domain will probably produce wrong or undesirable results
>(it may do that anyway, of course).  So program **authors** (which
>is who Paul was clearly referring to) do tend to care how well they 
>can model their real problem using the constructs of a particular 
>programming system.  Consumers, admittedly, just care about results.

As Paul said, it depends on your definition of "layprogrammer".
My impression of his argument was that Smalltalk's support for
polymorphism could be used to "woo" Basic/Cobol/RPG (or even C)
programmers to Smalltalk (as opposed to C++). And with that
definition in mind, my claim still stands (remembering that I
once was a Basic and then a C programmer -- I was never concerned
about "modeling the real world" until well after I was introduced
to OO).  YMMV, of course.

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

>Pointing out the flaws in C++ makes you angry, does it?

Hardly.  I use C++ all the time, and not even *that* makes me
angry (frustrated sometimes, but not angry).

>Well, that
>doesn't excuse your calling someone "ignorant" (by implication).

Indeed, "ignorant" was a very poor choice of words, and I apologize
if offense was taken.  In any case, I was merely attempting to steer
the conversation away from yet another Smalltalk-vs-C++ language
war, as such have never proven to be very productive on either side.

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