Xref: utzoo comp.lang.eiffel:1679 comp.object:3754
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!olivea!tardis!tymix!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Reference Semantics
Message-ID: <1193@tetrauk.UUCP>
Date: 19 Jun 91 10:10:20 GMT
References: <133154@tut.cis.ohio-state.edu> <1991Jun12.072557.7282@jyu.fi> <133644@tut.cis.ohio-state.edu> <1991Jun14.073249.1469@jyu.fi>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 32

>It is essential that several persons can have the same mother.
>On the opposite, a heart cannot be shared.  I consider it a deficiency
>of languages such as Lisp, Smalltalk, and Eiffel that this important
					   ^^^^^^
>semantic difference cannot be expressed; and the main reason is that
>references are used for "everything".

Sorry, Markku, you're not up to date with Eiffel.  From Eiffel 2.2 onwards
(that's nearly 2 years ago), a class variable can be declared as "expanded".
This means it gets value semantics - i.e. every assignment is a copy.  Eiffel 3
allows a _class_ to be declared as expanded, so every instance is distinct.  In
fact, in ISE's version of Eiffel 3, expanded objects will be _implemented_
using references, but the compiler will enforce _value_ semantics - i.e. it
will guarantee no aliasing.

You can do it both ways, it just happens that the default semantics are
reference.  I think this is quite reasonable, since I have found in practice
that extensive use of reference in Eiffel does not in fact cause problems,
despite the concerns raised by several people in this thread.  The comments
from Smalltalk users also confirm that references are not a real problem.

It is not difficult to build systems where references are the norm, and to
identify exceptions where alisasing must not be allowed.  The use of "expanded"
means these cases can be dealt with elegantly.  I believe this is a better
approach than taking value semantics as the norm, and then identifying cases
where aliasing is either required, or can be allowed for efficiency, and using
an appropriate syntax to make these the exceptions.
-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK		rick@tetrauk.uucp
Chairman, NICE (Non-profit International Consortium for Eiffel)

Any fool can provide a solution - the problem is to understand the problem