Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Reference Semantics (was: Functions without side effects)
Message-ID: <1178@tetrauk.UUCP>
Date: 7 Jun 91 09:35:22 GMT
References: <1991Jun3.145924.28406@mstr.hgc.edu> <130242@tut.cis.ohio-state.edu> <1177@tetrauk.UUCP> <131263@tut.cis.ohio-state.edu>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 47

In article <131263@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
>In article <1177@tetrauk.UUCP> I wrote:
>    ...
>>In fact I would suggest that a system in which large objects are used is best
>>handled using reference semantics, otherwise there will be a lot of
>>inefficiencies elsewhere resulting from copying. The programmer must of course
>>be aware of this, and use "clone" operations where required.
>
>I guess I did presume it was obvious that the strange side effects which
>result from the aliasing inherent in general reference semantics violated
>the comprehensibility requirement for reusable software.
>
>As it turns out, referencs semantics are fine -- provided you only allow
>_one_ reference to each object. (With this constraint, you effectively
>have value semantics, of course.) Now the problem, rephrased in these
>terms, is that our small object bias leads us to design classes with operations
>like Top which create multiple references to the same object. One of
>the challenges of object oriented programming is still to design classes
>so that excess copying can be avoided or (if you insist on reference
>semantics) so that multiple references can be avoided.

I strongly disagree that reference semantics are inherently a bad thing.  There
are a large number of real problems which require multiple references in order
to produce a reasonable soultion.  The general scenario is where a run-time
object represents the state of some part of the system, and may be updated by
asynchronous events.  If various other objects' behaviour is dependent on this
state, then they all need to refer to the common object.  If only single
references are allowed, then the events need to propagate their effects to all
relevant objects.  This creates far more complexity and difficulty than the
basic concept of multiple reference.

I suspect many people may be wary of using references as a result of
experiences with pointers in C, but C's pointers are open to far more abuse
than pure references.  I have found that one of the benefits of Eiffel is that
it makes a system with extensive use of references comprehensible and
maneagable (garbage collection is one of the essential components of this).
Although good OO design and programming systems can emphasise abstract concepts
and isolate a programmer from implementation details, it should never attempt
to hide the distinction between value and reference.  This is something that
both the designer and programmer must understand, and use both to best
advantage.

-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

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