Re: Orphaned Response

To: types@theory.LCS.MIT.EDU
Subject: Re: Orphaned Response
From: johnson@p.cs.uiuc.edu (Ralph Johnson)
Date: Thu, 20 Oct 88 15:17:21 EDT
Sender: meyer@theory.LCS.MIT.EDU
Date: Thu, 20 Oct 88 13:57:21 CDT

Bruce Kim wrote:  (KIM BRUCE-- ARM, moderator)
>The more I look at object-oriented programming, the more I believe
>that there are at least two different, perhaps equally important,
>notions floating around.  One certainly is the notion of inheritance of 
>representation of subtype from a supertype (this is the motivation for using 
>coercions to model subtype).  However, equally important is the notion of
>code reuse (see Liskov's article in the supplement to OOPSLA '87, among others,
>for some hints on this).  That is, because of structural considerations, if I
>have a function which does things to certain fields of a record, then it will
>also work similarly on another record type that has (at least) those same
>fields.  In most object-oriented languages, these two uses seem to be mushed
>together, although this does not seem necessary.

I am not an expert on type theory, but I do have a lot of experience
with object-oriented programming.  We are building an optimizing compiler
for Smalltalk and have developed a type system for it, hence my interest
in this list.  Bruce is absolutely correct that inheritance and "code reuse"
are two separate notions.  In Smalltalk they are not mushed together at all,
but most strongly typed o-o languages do combine them.  In my opinion,
people looking at type system for o-o languages over-emphasize inheritance
and ignore message sending.

The "correct" term (from a Smalltalker's point of view) for what Bruce
calls "code reuse" is "message sending".  An object invokes an operation
on another object by sending a message to it.  The implementation of
the operation (i.e. the method for the message) is determined at run-time
by the class of the receiver.  This late binding of procedure calls
results in a sort of polymorphism.  If a procedure sends messages X and Y
to one of its arguments then it can be given any object that understands
X and Y, no matter what class they are in.  Thus, Smalltalk programmers
think of a type as a set of messages.  (Actually, they think of type in
other ways, too).  It doesn't matter what class an object has, or whether
it has a particular class as its superclass, only what operations it has.

If you define "field" to be ONLY the operations on an object (i.e. the
methods defined by its class) then this notion of type is nearly the same
as the standard one.  However, inheritance then means type inclusion,
not class inheritance, and the application to object-oriented programming
is quite different than it might seem to the causual observer.  At first
glance, one might think that the instance variables of an object make
up its fields, but they don't have anything to do with its type.

When I first read Cardelli's distinction of inclusive polymorphism
and ad-hoc polymorphism, I said to myself "Ad-hoc polymorphism is
the important kind".  I don't believe as strongly in that as I used
to, because it is possible to think of the fields of an object as
its operations, not its instance variables, and to realize that
inheritance of type is entirely orthoganal to inheritance of class.
If you look at it from that point of view, the classical approach to
a type system for an object-oriented programming language makes sense.

Ralph Johnson