Path: utzoo!utgpu!watmath!att!dptg!rutgers!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!aero!abbott
From: abbott@aerospace.aero.org (Russell J. Abbott)
Newsgroups: comp.lang.smalltalk
Subject: Re: Performance of "doesNotUnderstand:"
Message-ID: <56929@aerospace.AERO.ORG>
Date: 30 Aug 89 15:14:38 GMT
Reply-To: abbott@itro3.aero.org (Russell J. Abbott)
Organization: The Aerospace Corporation, El Segundo, CA
Lines: 61

I've been playing around with Smalltalk for a few weeks now and still
feel like a novice.  As you know, Smalltalk does not have declared
types.  "Type checking" is basically done dynamically: if an object has
a response defined for a message sent to it, then it is of the "right
type."  In trying to understand what that means, I came up with the
following.  I'm sure this must have been worked out properly somewhere.
Does anyone know where?

(In _Smalltalk-80: The Language_, by Goldberg and Robson, the word
"type" does not appear in the index.)

     ----------------------------------------------------------------

In Smalltalk, a type is a set of "messages" that objects of that type
can receive.  That is,

Type ::= {Msg1, Msg2, ..., Msgm}

where a message is a message name, a list of the types of the
parameters, and the type of the result, i.e.,

Msg ::= Name(param1: Type1; param2: Type2; ..., paramn: Typen): Type

The actual type names are not important.  In fact, they are never used
and simply represent this structure.  The message names are important
and play the role of constants of some sort.

The following two definitions are circular (as, I suppose are the
preceding definitions), but I don't see immediately how to fix it.


A message M1 is less demanding than a message M2 if:

(a) M1 and M2 have the same message name and the same number of
parameters;

(b) the type of each of M2's arguments is a specialization of (i.e., is
more specific than, accepts at least the same messages as) the type of
the corresponding argument in M1.  (In other words, M1 requires less of
its arguments than does M2.)

(c) M1's returned type is a specialization of the returned type of M2.
(That is, M1 returns an object that can do at least as much as the
object that M2 returns.)

If M1 is less demanding than M2 then:
if object O1 accepts M1 and object O2 accepts M2 then the call

		O2 M2(P1, P2, ..., Pn)

could be replaced by

		O1 M1(P1, P2, ..., Pn)

and no type conflict would result.


A type T2 is a specialization of (i.e., more specific than) type T1 if
each message in T1 is less demanding than some message in T2.
-- 
-- Russ abbott@itro3.aero.org