Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!news.ecn.bgu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!newsfeed.internetmci.com!news.kei.com!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: <DJK6yy.59C@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> <DJGGHo.90K@cunews.carleton.ca> <yf3hgz4bryi.fsf@sabi.demon.co.uk>
Date: Thu, 14 Dec 1995 04:25:45 GMT
Lines: 195

In article <yf3hgz4bryi.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>>>> On Tue, 12 Dec 1995 04:01:00 GMT, dbuck@superior.carleton.ca (Dave
>>>> Buck) said:
>
>dbuck> A class is easy to define in the context of Smalltalk.  Every
>dbuck> object in Smalltalk is an instance of a class.  As far as I know
>dbuck> there are no possible exceptions to this.  The class itself is an
>dbuck> object which stores the methods which can be executed for its
>dbuck> instances.
>
>I have been thinking of this first stumbling block again, in which you
>start to describe a version of ``Smalltalk'' totally unlike
>Smalltalk-80, one in which classes are not linguistic constructs
>_represented_ by class objects as in Smalltalk-80, but by definition
>_are_ class objects, so that class and class object are synonyms.

This is indeed our first stumbling block.  We have two different
possible definitions of 'class' that start out with:
   1) a class is an object that ...
   2) a class is a linguistic concept that ...

Let me refer to the first as the 'class object' and to the second as
the 'conceptual class'.  If we define 'class' to mean 'class object'
we are saying that a class has state and behavior and exists in the
memory of the computer.  If we define 'class' to be 'conceptual class'
then we are saying that the class is a concept which may be
represented in the system by a class object.

We routinely (for better or for worse) use terminology in OOP that
doesn't distinguish between a thing and the computer model of that
thing. If I created a class for a Car and created instances of it, I
would say things like "this variable contains a Car" and "we tell the
Car to start."  Everyone knows that variables can't contain actual
cars and that cars in the real world don't start by voice commands.
Normally, it's quite clear that the computer model is not the same
thing it's a model of.

Sometimes, though, it's not so clear that there's a distinction
between something in the real world and its computer model.  Consider
a Smalltalk Block like [:x | x squared].  Is there a real-world entity
for which this is a model?  Is the real-world entity the same thing as
the model?  I won't try to answer this, but I do consider it to be
less obvious.

In the case of 'class' we have become accustomed to using the term to
refer to the model itself and not think too much about the linguistic
concept that it models.  This confusion is even present in the Blue
Book.  (Thanks to Piercarlo for typing in these quotes):

 "A _class_ describes the implementation of a set of objects that all
  represent the same kind of system component." ... "Programming in
  the Smalltalk-80 system consists of creating classes, creating
  instances of classes, and specifying sequences of messages among these
  objects."
  [Classes and Instances, page 8]

For the first sentence, either definition of 'class' seems to work for
me.  In the second sentence, the concept of 'creating classes' seems
to apply more to the 'class object' interpretation than the
'conceptual class' interpretation.  I would think that if they were
referring to a conceptual class, they would use 'define' rather than
'create'.  In any case, it's very ambiguous which interpretation they
mean and doesn't 'prove' either side.

Here's another quote from the Blue Book:
 "*class* An object that describes the implementation of a set of
  similar objects." [Summary of terminology, page 53]

This definition clearly leans to the 'class object' interpretation. I
can't map the term 'conceptual class' to this definition.  You have
already protested this definition:

pcg>  which should read:
pcg>  "*class* the description of the implementation of all objects of
pcg>     the same type, which is represented as an object
pcg>     itself."

Another quote from the Blue Book, however, clearly leans in the other
direction:

   "Since all Smalltalk-80 system components are represented by
   objects, and all objects are instances of a class, the classes
   themsleves must be represented by instances of a class."

The definition of 'class' meaning 'class object' doesn't seem to fit
the above definition.

Ok.  Having said all this, we have some basis to define 'class' to be
either definition.  I suspect that if we chose the definition of
'class object' that you would agree that it's not at all the same as a
type.  Am I correct?

Let's, however, continue with the definition of 'class' as 'conceptual
class' as you suggest and see where it leads us.

>Let me ask: suppose you wanted to define in your ``Smalltalk'' a class
>to be something else than a class object, perhaps a linguistic
>construct, could you try to imagine how it would look like?

First off, I believe my previous arguments demonstrate that there is
at least some level of confusion even in the Blue Book about whether a
'class' is defined as a 'class object' or a 'conceptual class'.  I
would like to propose that whatever the definition of 'class', the
'Smalltalk' language is the same.  The way we talk about it may be
different.  Therefore, arguing that 'my Smalltalk' is different than
'Smalltalk-80' is irrelavent.  If you don't accept this, fine.  We can
still move on.

I would define a 'conceptual class' as (stealing your words because
they state it quite well): "the description of the implementation of
all objects of the same type".  I removed the ending "which is
represented as an object itself" since having a concept doesn't
necessarily imply that I must actually implement a model of that
concept.  I also don't like using the word 'type' just yet because I'd
like to first decide what a 'class' is before trying to relate it to
what a 'type' is, but for now, I'll let the definition stand.

I would consider that since this is a description of an
implementation. This description must include:

   1) the name of the class
   2) the names of all instance variables for that class
   3) the conceptual superclass of this conceptual class
   4) the exact description of all methods for this class
      including the exact method names and exact semantics (no
      variations on semantics are allowed at all).

It's possible to model a real-world object in many different ways.  I
would consider each possible way to be a separate 'conceptual class'.
Any change in the class name, instance variable names, the superclass,
method selectors, or method semantics would constitute a different
conceptual class.

From this definition, it's only possible to have one implementation of
a 'conceptual class' in Smalltalk at any one time unless we start
considering light-weight classes or a new 'Smalltalk with namespaces'.
The reason for this is that Smalltalk stores the class objects in a
global dictionary with the class name as a key.  Since any
implementation of a 'conceptual class' must by the above definition
have the same name, only one such class object can exist in the
system.

If we allow lightweight classes, the class object isn't stored in the
global dictionary, hence many implementations of them may exist
simutaneously.  If we have a new 'Smalltalk with namespaces', we can
store the class objects in different dictionaries allowing us to have
several simultaneous implementations.  I suggest that we disregard
these scenarios in this discussion since they are foreign to the
conventional Smalltalk philosophy.

At this point, I'll stop because I expect you'll want an opportunity
to provide a rebuttal or an alternate definition of a conceptual
class.  I have probably defined this to be too restrictive for your
liking.

>  BTW, perhaps I should state here that I do accept as valid (inasmuch
>  it is meaningful and relevant) your contention (that I think has been
>  shared by many other people with which I have discussed the issue)
>  that, in the ``Smalltalk'' you describe, class objects (your
>  ``Smalltalk''s definition of class, as I understand it) are not in
>  any way equivalent to protocols+semantics specifications (which is
>  what I understand to be the definition of type you have stated as 
>  being the one that most ``Smalltalk'' people use).

I would agree.  A specification of how something behaves is not an
object.  It's possible to model this specification with objects, but
then you have a model of a specification not a specification itself.

>I have no objection as to this change of direction, because it might
>well clarify matters also as to the relationship between Smalltalk-80
>classes and Cardelli&Wegner/Meyer types, which I still maintain to be
>one of essential identity (not having seen for weeks any argument by
>anybody actually being about the claim I made, except for those that
>agree with it), which would mean that Smalltalk-80 is indeed a (strongly
>but dynamically) typed language in the Cardelli&Wegner/Meyer sense of
>the word.
>
>Sorry for the very dense paragraphs above, but I have tried to be
>precise as to what I see as the discussion is about right now.

Precision is required in this kind of debate.  I do have questions
about "strongly but dynamically typed" but I'll wait until we talk
about types before I ask them.  Right now, I want to try to get some
agreement on 'class' if we consider it to be a 'conceptual class'.

David Buck
dbuck@ccs.carleton.ca

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

