Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!bloom-beacon!eru!luth!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.object
Subject: Re: Atomic Objects and Identity (was Re: Evaluating "Object-Oriented" Progra)
Message-ID: <2930@tukki.jyu.fi>
Date: 5 Feb 90 15:17:35 GMT
References: <2740@tukki.jyu.fi> <1990Jan31.052750.22507@Neon.Stanford.EDU> <MOSS.90Feb1095903@takahe.cs.umass.edu>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Distribution: comp
Organization: University of Jyvaskyla, Finland
Lines: 54

In article <MOSS.90Feb1095903@takahe.cs.umass.edu> Moss@cs.umass.edu writes:
>I want to make a brief follow up comment regarding mutability and identity.
> ...
>objects. *Immutable* objects should act like pure mathematical values (even if
>they don't fit into a small number of bits), and distinct copies of them
>*should not* be distinguished. (Almost) every mutable type (class, abstract
>data type) also has an immutable version, where each mutating operation of the
>mutable type instead produces a new immutable value without changing any of
>its inputs. Further, both can be useful to have around. In sum, the identity
>of an *immutable* object *is* its (abstract) value. Testing identity may not
> ...

There is a lot of sense there. However, I would say that one *can* regard
immutable objects as abstract values (with the provision below), but one
is not forced to. For instance, it could be a sensible operation to
"freeze" an originally mutable object to immutability: should it lose
its identity then?

>
>Another point to keep in mind is that an object/class can be immutable and yet
>*refer to* mutable objects. For example, consider an immutable set of airline
> ...
>(snapshots), too, but that is a different abstraction.) One must be especially
>careful with collections (not meaning the Smalltalk class, but every abstract
>data types that is essentially a collection (more or less structured) of
>other, independent objects) not to get tangles up about mutability.
> ...

Right. My point of view is that an immutable object that (directly
or indirectly) refers to some mutable object cannot be considered an
abstract value. In a draft paper, I suggest the term 'totally immutable'
for objects that can - the definition should be pretty obvious.

>
>A final note -- none of this stuff is directly related to inheritance. We
>thought through many of the issues in designing CLU, a language supporting
>abstract data types but not inheritance, in the early 70s.

One should certainly not stop learning from languages like CLU and Ada
just because they are not "object-oriented". Although CLU has the same
flaw (in my opinion) as Smalltalk that it does not allow mutable objects
of atomic types, it is more orthogonal than Smalltalk by allowing
immutable constructed types. However, I would like to
consider mutability not as an aspect of _type_, but independent of it.
That's the way "conventional" programming languages usually treat it,
only they may not always have syntax for expressing constants of
arbitrarily complex types.

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