Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!fuug!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@jyu.fi (Markku Sakkinen)
Newsgroups: comp.object
Subject: Re: value semantic versus reference semantic
Keywords: Smalltalk, distribution, values, object identity, immutability
Message-ID: <1991May22.053938.20827@jyu.fi>
Date: 22 May 91 05:39:38 GMT
References: <1991May14.093053.3017@jyu.fi> <3683@sequent.cs.qmw.ac.uk> <4851@osc.COM>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 70

In article <4851@osc.COM> jgk@osc.COM (Joe Keane) writes:
>The whole idea of asking for all instances of a class is wrong.  Such a
>facility should not be provided.

This is somewhat too strong an opinion.  Funny that it comes from a person
working for an OODB company (right?) -- especially many object database
people often think that the "class as collection" aspect is also necessary,
and it is analogous to most other database models.  Example advantage:
 - class (or schema) evolution:  one often has to convert all existing
   instances to fit the new class definition.
Example disadvantage:
 - clashes with access rights in a database:  e.g. what is a user entitled
   to know about possible instances not accessible to him/her in a class?

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

Rather natural in a language in which even classes are first-rate
runtime objects; e.g. the mentioned advantage for class evolution holds.
(In fact one can contend that ordinary classes are the _only_ first-rate
objects in Smalltalk, and both instances and metaclasses somewhat crippled,
but that's another story.)

>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.

Perhaps it could be a part of a language, but only as an option
for each class.  Everybody who needs it would then not have to
"roll his own".

> ...
>A class is an abstract entity.  It defines a set of possible instances, and a
> ...

No, it isn't only an abstract entity even in C++ if it has "static members"
(class variables).

> ...
>We also want to talk about sharing value.  Relating object-oriented and
>functional terminology, an object is a reference, which refers to some value.
> ...

Well ...  Conceptually, from an Algol 68 -like viewpoint, you can say that.
But in actual OOPL's (most certainly in C++) objects are not references
but containers of values.  This makes an important difference in the
following.

> ...
>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
> ...

Not quite so, although the main principle is good.  The programmer must
define a "front end" class for the objects that clients are allowed
to see, and a "back end" class for hidden objects to which the visible
objects contain references.  The back end objects then contain the
actual data and reference counts, and the above tactic can be applied
to them.

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)