Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!uwm.edu!chi-news.cic.net!nntp.coast.net!torn!nott!cunews!dbuck
From: dbuck@superior.carleton.ca (Dave Buck)
Subject: Re: Smalltalk-80: The Language
X-Nntp-Posting-Host: superior.carleton.ca
Message-ID: <DJGGHo.90K@cunews.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Organization: Carleton University, Ottawa, Canada
References: <goochb.185.0012818B@rwi.com> <yf3wx83yv35.fsf@sabi.demon.co.uk>
Date: Tue, 12 Dec 1995 04:01:00 GMT
Lines: 152

To Piercarlo Grandi (any anyone else intersted in responding):

In my experience, the people in the Smalltalk community generally
consider Smalltalk to be untyped and generally consider types to be
different and distinct from classes although there are some
similarities.  In this message, I will try to explain how we define
and use the terms 'type' and 'class' and what they mean to
us when we develop software.  I would be interested (seriously) in
hearing your views on these interpretations and, if you disagree, how
you would modify the definitions.  I'm not, however, interested in
being chastized, insulted, ridiculed, or slandered for saying these
things.  In turn, I will not cast the first stone.  What I'm
seeking here is a mutual understanding.  Also, please keep in mind
that I'm writing this away from home and don't have access to my
usual reference material so I'm unable to provide quotes or
references.  Let's keep it civil and see if we can come to some
resolution on this. Please forgive me if I repeat things that you
already know and understand.

A class is easy to define in the context of Smalltalk.  Every object
in Smalltalk is an instance of a class.  As far as I know there are no
possible exceptions to this.  The class itself is an object which
stores the methods which can be executed for its instances.

Every class has zero or one direct superclass.  By this, I mean that
the class object has an instance variable which can be nil or another
class.  I realize that "Smalltalk-80: The Language" doesn't state this
quite as loosely, but it's a commonly accepted and commonly used part
of the language so I'll keep it.  For the moment, I'm happy leaving
multiple inheritance out of the picture.  Classes are normally
subclasses of Behavior.  I don't remember ever seeing this rule broken
and I'm sure there are some implementation details that would make it
difficult to break this rule.

Notice that I've defined classes to have superclasses rather than
saying that classes have subclasses.  This is for a good reason.  As
Jan Steinman pointed out earlier, it's possible to have 'light weight
classes' in Smalltalk.  My understanding of this is that it's possible
to create a class that has a superclass but doesn't show up in the
superclasses' list of subclasses or in the Smalltalk global
dictionary.  In this way, when all instances of that class get garbage
collected, so does the class itself.  If this understanding isn't
correct, I'd welcome a correction.

The set of all methods in an object's class and all superclasses of
that class form the object's protocol with the methods in the
subclasses overriding those with the same name inherited from their
superclasses.  This set of methods determines the basic behavior of
the instances of the class.  There's one catch here, however.  It's
possible (and fairly common) to override the doesNotUnderstand: method
in Smalltalk.  This message is sent to objects whenever the message
lookup failed to find a method in the receiver's class or any of its
superclasses.  The default doesNotUnderstand: method produces an error
message.  By overriding doesNotUnderstand:, however, we can choose to
handle the message in a different way.  We can, for example, send the
message to another object which does understand it.  The value
returned from that message send is returned as the result of the
message that wasn't understood.  This is what Jan Steinman refers to
as "General Delegation".  In most cases, classes that define
doesNotUnderstand: methods are also subclasses of nil (i.e., they have
no superclass).  In this way, almost all messages are forwarded to the
delegation object.

One more note about classes.  Although subclasses always inherit all
methods from their superclass, it's possible to override a method to
produce an error message.  This is usually considered undesirable but
it's often a good way to solve some problem.  It's also possible for
subclasses to be more restrictive about method parameters than their
superclasss.  Again, this is undesirable if it can be avoided.

Ok.  Now for types.  Some people have suggested that in Smalltalk, a
type is a set of selectors (message names) that an object responds to.
I would disagree or at least extend this definition.  Whereas a class
answers the question 'how does this object respond to messages?', a
type answers the question 'where can I use this object?'.  Although
not explicitly defined in Smalltalk, a type corresponds to a set of
message names along with the number and types of the parameters and
the implied semantics of the method.  The semantics are very difficult
to specify precisely.  The semantics need not be identical to consider
two objects to be the same type, but they must somehow do the same
job.  For example, a SimpleInterest object calculates interest
differently from a DailyCompoundingInterest object but the
calculateInterest method for each does the same job with respect to
each object.

What does this buy us?  It allows us to classify objects by the roles
they can play.  Each type corresponds to a role.  By describing
parameters, variables, and return values in terms of these roles, we
can define (albeit loosely and externally to Smalltalk) what behaviors
an object must have in order to be acceptable as a value for this
parameter, variable, or return value.

Now, let's look at the the types in terms of the class hierarchy.
It's possible to define a role independent of the class hierarchy.
This is what Alan Lovejoy meant (correct me if I'm wrong) when he said
that the class hierarchy is an implementation artifact.  I can, for
example, create an object that contains the same protocol as a Stream,
accepts the same types for the parameters for each message in the
protocol, returns the same types of values as return types and has the
same 'basic' semantics as a Stream but isn't itself a subclass of
Stream.  One example is the Transcript in Smalltalk.  The Transcript
is actually a window and exists in the GUI hierarchy.  It can,
however, respond to nextPut:, nextPutAll:, cr, space, etc. in the same
way as a Stream.  We can, therefore, consider it to be the same type
as Streams since we can use it anywhere we can use a Stream.

Subclasses can override methods in superclasses to produce error
messages.  This means that they no longer do the same 'job' as the
superclass.  If that 'job' was defined to be a behavior necessary for
some type, the instances of the subclass would not belong to that type
even though instances of the superclass would.  As an example, in
Smalltalk, the class Dictionary is a subclass of the class Set.  The
definition of add: for Set allows you to add any object so long as it
responds to hash and = in the normal ways.  The add: for Dictionary
requires that the items added respond not only to hash and = but also
to key and value.  You can argue, therefore, that the Dictionary class
isn't type compatible with the Set class.  This is an example where a
subclass doesn't belong to the same type as the superclass.

General delegation also throws a kink into things.  It's possible to
have a delegation object that forwards all of its messages to a Set
for example.  You can then use this delegation object in the role of a
Set and the system will accept it and operate correctly.  In this
case, the methods needed to provide the Set-like behavior are not
present in the delegation object's class or any of its superclasses,
yet the object can still be used as a Set and nobody would ever know
the difference.

I hope that this (long-winded) explanation clears up some of the
confusion concerning classes and types.  I look forward to your reply.
If you wish to continue to argue that a class and a type in Smalltalk
are the same thing, please provide a definition of a type that you
like and accept.  I know that you posted a definition in a previous
message that defined the mathematical definition of a type.  I was
very interested in this definition, but unfortunately, there was some
missing information which didn't allow me to properly evaluate it.
Specificically, it defined a type as a subset of all values $V$ that
satisfied some criteria but the excerpt didn't mention what those
criteria were.  Without that information, I'm not able to properly
evaluate this definition and compare it to what we call a class in
Smalltalk.

Regards,

David Buck
dbuck@ccs.carleton.ca

_________________________________
| David K. Buck                 |
| dbuck@ccs.carleton.ca         |
| The Object People             |
|_______________________________|
