Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!think!snorkelwacker!apple!agate!shelby!neon!pallas
From: pallas@Neon.Stanford.EDU (Joe Pallas)
Newsgroups: comp.object
Subject: Re: Evaluating "Object-Oriented" Progra
Message-ID: <1990Jan16.181047.18863@Neon.Stanford.EDU>
Date: 16 Jan 90 18:10:47 GMT
References: <638@ajpo.sei.cmu.edu> <135300024@p.cs.uiuc.edu> <2704@tukki.jyu.fi>
Organization: Computer Science Department, Stanford University
Lines: 31

In article <2704@tukki.jyu.fi> sakkinen@tukki.jyu.fi (Markku Sakkinen) writes:

>However, the main reason why instances
>of the basic atomic classes of Smalltalk don't look like first-class objects
>to me is that they are immutable (while instances of normal classes
>are mutable) ...

Instances of ``normal classes'' are only mutable if they have instance
variables.  Classes with no instance variables (and, hence, immutable
instances) may not be common, but they are both possible and useful.
(Example: Booleans)

>... and they can be neither created (thus there can be no
>initialisation methods) nor deleted, at least conceptually.

On the contrary, conceptually they are created and deleted [whatever
that means with GC] all the time.  It's the implementation that does
not actually create and destroy them, for efficiency's sake.  The
implementation can do that precisely because it makes no difference at
the user level.

As an exercise, try to write a Smalltalk expression (without using
explicit identity tests) that will yield different results when a and
b are the same instance of such a class and when they are different
instances of such a class.  It's not hard to see that if there are no
instance variables, all instances have the same behavior (excepting
explicit identity tests, which most implementations do not allow to be
redefined).  And, logically, if they always behave the same you can't
tell them apart.

joe