Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!pacbell!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.object
Subject: Re: value semantic versus reference semantic
Summary: A class shouldn't know its instances.
Keywords: Smalltalk, distribution, values, object identity, immutability
Message-ID: <4851@osc.COM>
Date: 20 May 91 23:47:50 GMT
References: <68780001@hpcupt1.cup.hp.com> <1991May14.093053.3017@jyu.fi> <3683@sequent.cs.qmw.ac.uk>
Reply-To: jgk@osc.COM (Joe Keane)
Organization: Versant Object Technology, Menlo Park, CA
Lines: 50

The whole idea of asking for all instances of a class is wrong.  Such a
facility should not be provided.

It's part of Smalltalk, and certainly Smalltalk programmers will exploit it to
do whatever nasty little tricks they feel they need to do.

Fortunately, in my opinion, it's not part of C++.  People complain that they
want it, and even come up with situations where it appears to be useful.  If
you want to put such a facility in your class, that's your own business, and
no one should try to stop you.  But it shouldn't be a part of the language.

Please note that i'm not claiming that C++ is better than Smalltalk.  Let's
not get into a language war.  I just prefer the way it does some things.

A class is an abstract entity.  It defines a set of possible instances, and a
protocol which works on these instances.  You may have instances of this class
in your workspace, on your disk, on another machine, and so on.  This doesn't
change the class.  What does it mean to ask for the instances of a class?

We may allow that the state of a class includes a list of its instances.  Then
the class changes when instances are created or destroyed.  What's more, the
`same' class on two different machines will actually be two different things.
Like i said, some people may think this is a good idea, but i'd rather stick
with the old abstract definition in terms of possible instances, rather than
the instances which currently exist in some workspace.

Perhaps for some low-level operations it may be useful to determine which
instances of some class are in some area of memory.  But surely this is an
implementation detail, and such an ugly thing should not be exposed in a
high-level language.

We also want to talk about sharing value.  Relating object-oriented and
functional terminology, an object is a reference, which refers to some value.
Values are immutable, while references are not.  People have talked about
immutable objects.  These are a special case: since the reference always
refers to the same value, we can eliminate a level of indirection, and say
that the object is a value.  It's certainly useful to be able to share values
between different, possibly unrelated, references.  You can save space, and it
also helps out caching/memoization if you do that.

But the same argument applies to mutable objects too.  If two mutable objects
happen to have the same value, they can still share space for it.  Then if one
of the objects is changed, you have to copy its value before making the
change.  This is analagous to `copy on write' for pages in a virtual memory
system.  Or you may want to have some sort of delta versioning scheme, if you
don't expect both objects to have heavy use.  Note that `object identity' is
determined by the reference, not the value, so there is no problem with that.
--
Joe Keane, professional C++ programmer
jgk@osc.com (...!uunet!stratus!osc!jgk)