Path: utzoo!attcan!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.object
Subject: Re: Evaluating "Object-Oriented" Progra
Message-ID: <2704@tukki.jyu.fi>
Date: 15 Jan 90 12:40:04 GMT
References: <638@ajpo.sei.cmu.edu> <135300024@p.cs.uiuc.edu>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 53

In article <135300024@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
>
>Markku Sakkinen wrote:
>>Question: However, isn't it actually bogus that all fundamental things
>>in _Smalltalk_ are first-class objects? For instance, how do you define
>>a use a meaningful subclass of SmallInteger, adding at least one
>>instance variable?
>
>SmallIntegers are implemented by a hack (use of a tag bit) so, as far as
>I know, none of the Smalltalks let you subclass SmallInteger.  However,
>this is not a problem in practice, since it is easy to subclass Integer,
>and all you have to do is make a new kind of Integer whose value is a
>SmallInteger and that delegates a few important operations (+,-,/,*,<,=)
>to its value.  Such a subclass will work like a SmallInteger and you can
>easily add new methods or variables to it without interfering with
>regular SmallIntegers.
>
>This is an extreme example of a general property of inheritance: it is
>usually a lot cleaner to inherit from abstract classes than from concrete
>classes.  It is quite common for a subclass to need a different data
>representation, but inheritance brings along the superclass's data
>representation.  

Thank you for the information. 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) and they can be neither created (thus there can be no
initialisation methods) nor deleted, at least conceptually.

In contrast, if the programmer defines a subclass, say MyInteger (concrete),
of the abstract class Integer, then instances of MyInteger are entirely
ordinary objects; they will obey "reference semantics" instead of the
"value semantics" of built-in integer types. As an example, suppose
some method of class Car contains
   price <- anotherCar price
If the price object is a MyInteger, this assignment will cause sharing,
quite unlike ordinary integers.

So it seems unwise to define any subclasses of Integer and similar
built-in classes: they might cause unpleasant surprises to users later.
This holds for type-checking derivatives of Smalltalk (see e.g. Johnson's
paper from OOPSLA'86) as well, since MyInteger _is_ formally a subclass
of Integer.

Disclaimer (again): because of no practical experience with Smalltalk,
the above may be incorrect in technical details.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland