Newsgroups: comp.lang.smalltalk,comp.object
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!howland.reston.ans.net!ix.netcom.com!netcom.com!milod
From: milod@netcom.com (John DiCamillo)
Subject: Re: Polymorphism One More Time
Message-ID: <milodDoA4Lo.6H5@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> <milodDo831M.J5F@netcom.com> <31478404.311D@concentric.net>
Date: Thu, 14 Mar 1996 22:46:36 GMT
Lines: 141
Sender: milod@netcom16.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:36006 comp.object:45909

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

>Polymorphism makes substitutability possible.  That was, I believe,
>the intended implication of Paul's definition.   The only claim
>that they are identical has come from your interpretation of Paul's
>definition--I certainly have no intention of claiming such, and I didn't 
>detect any such intention from Paul's definition.  I doubt that that
>is what he meant to imply.  Perhaps there is a rewording of the
>definition that would remove this unintended implication?

A short one?  Probably not :-)

>Semantics and philosophy are very general subjects.  Computer science is 
>rather more specific.  There are many analogies in the real world to the 
>polymorphism found in programming languages.

I agree. And yes, they are analogies. The polymorphism defined in
type theory seems more precise. (to me)

>There was recently another 
>post on this thread that gave an example: the auto-body shop that can work 
>on many different types of vehicles--and other machinery. In the real
>world, a "container" can hold any object that satisfies the size constraints
>imposed by the container.  Who ever heard of a statically type-constrained
>jar that accepts jam but not coins?

And of course the rebuttal goes: at the breakfast table, I would prefer
a container that did have both jam and coins.  And also at the bank.
But that seems to be just a question of static versus dynamic typing.
It is of course possible to define such a promiscuous container in
either Smalltalk or 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.)

>Ah! "All values are objects" is much better than the traditional phrase
>"everything is an object."  Of course, there are elements in the semantic
>space of Smalltalk (and all other programming languages) that are not
>(and in some cases, perhaps cannot) be treated as "values." It is often
>possible to "cheat" so that these things can be treated as values
>only when someone is looking (e.g., thisContext, #doesNotUnderstand: aMessage).

>But it is also true that if there are "objects" (in the normal English meaning 
>of the term) in the semantic space of a programming language that cannot be
>treated as values, then that discontinuity in the denotational semantics
>reduces the polymorhpism of the language as a whole.  So Smalltalk has
>a greater degree of polymorphism than a language where classes cannot
>be treated as values.

True enough, in that regard.

>And methods in ST80 have always been objects.  A method can access itself
>as it runs: "thisContext method" gets you the object that is the currently
>executing method.  That's been there longer than I've been doing Smalltalk
>(ten years).

Well, I stand by my statement, but I must qualify it. Methods were not
objects in Smalltalk/V for Windows in (approx) 1992.  There is no "class
Method" in that implementation, and "Context" does not understand the
message "#method" -- according to some dusty manuals on my bookshelf.

[...]

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

>Why are there no such languages?

A number of reasons, I would imagine.  Higher-order functions
originated(?) with LISP which is dynamically typed, and are quite
common in dynamically typed languages derived directly or indirectly
from LISP (like Smalltalk).  Higher-order functions are also quite
common in statically typed functional languages like SML and Haskell.
The ML-2000 crowd appears to be investigating adding OOP to SML, and
Haskell has a taste of OO in type classes.  But they aren't there
yet, partly because of theoretical problems with defining Self types
in Hindly-Milner type systems.

Most statically typed OOPLs are derived from statically typed non
OOPLs that didn't have higher order functions to begin with, and no
one saw fit to 'taint' them with LISPy features.  Other statically
typed OOPLs (such as Eiffel) were trying to be minimalist, and not
include anything that was not directly applicable to OO.  Sather
provides a similar concept with it's 'iters'.

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

>I can live with "constrain" instead of "inhibit." Polymorhpism is not
>an all or nothing property.  C++ has more of it than does C, but less of it 
>than does Smalltalk.

But this has never been about C++ vs. Smalltalk.  If anything,
it may have been about static versus dynamic typing, and the
different sorts of polymorphism provivded by such languages.

>There is a place in this world for assembly language, a "C"-like
>language (I prefer Modula-2), a "C++-like" language (I prefer Eiffel),

Meyer would be rolling over in his grave if he weren't still alive!
Eiffel a "C++-like" language?  Heaven forbid. :-)

>and a Smalltalk-like language.  And in the future, Self-like languages
>(hey, I didn't name it) will have their place, too.

One would hope.  Although perhaps not Self, itself -- I heard Sun
has killed it.  Perhaps Cecil or Obliq...

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