Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@jyu.fi (Markku Sakkinen)
Newsgroups: comp.object
Subject: Re: value semantic versus reference semantic
Message-ID: <1991May14.093053.3017@jyu.fi>
Date: 14 May 91 09:30:53 GMT
References: <68780001@hpcupt1.cup.hp.com>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 59

In article <68780001@hpcupt1.cup.hp.com> thomasw@hpcupt1.cup.hp.com (Thomas Wang) writes:
>
>I am looking at the issues of value semantic versus reference semantic.
>
>The value semantic says that  a := b;  means the value of 'b' is copied
>to 'a'.
>
>The reference semantic says that  a := b;  means 'a' is pointing to the
>same place as 'b'.

Right, and note that almost all OOPL's offer only reference semantics
for objects.  C++ is one of the refreshing exceptions.

>It has occurred to me that value semantic is equivalent to reference
>semantic if the value of 'b' can never change.  So one can use reference
>semantic on immutable classes, and expect them to be well behaved.

To avoid all ambiguity, it might be better to speak of immutable _objects_.
I must admit another good point in C++ (newer versions): immutability
('const') is not an attribute of a class but rather of a variable or object.
There seems to be the bad point in Smalltalk that one really cannot define
sensible immutable classes, because there is no distinction between
the initialisation and the modification of an object.  (Smalltalk experts:
is there a way around this problem?)

In reference-based languages, for an assignment to be equivalent to
value semantics, it is usually not sufficient for the assigned object to be
immutable itself;  it must be "recursively immutable" in the worst case.
But note that with reference semantics there is even no general definition
of the "value" of an object:  usually it is something between "shallow value"
and "deep value".

>However, it seems the running speed of program using immutable classes
>can be slower than an equivalent program using mutable classes, since so many
>garbage objects can be generated by the immutable version.
>The question is 'are there optimization algorithms that can improve
>the performance of immutable classes?'

There should be people in this group who know some answers to the question,
but so far I haven't seen any.  However, I have some doubts about
the relevance of the problem:
1. If you are modelling mutable entities with your software, why should
   you use immutable objects in the first place?
2. If you really need immutable objects, there will not be generated
   many garbage objects.

I.e., use both mutable and immutable objects according to where
each alternative is more appropriate.  Personally, I do not believe
in "applicative object-oriented languages" (if that's what you had
at the back of your mind), except perhaps for very special applications
(pun not originally intended, but it came for free).

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)