Xref: utzoo comp.lang.eiffel:1636 comp.object:3675
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Reference Semantics
Message-ID: <1181@tetrauk.UUCP>
Date: 10 Jun 91 11:30:11 GMT
References: <1177@tetrauk.UUCP> <131263@tut.cis.ohio-state.edu> <1178@tetrauk.UUCP> <131691@tut.cis.ohio-state.edu>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 68

In article <131691@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
|>>     ...                       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.
|
|In article <1178@tetrauk.UUCP> I wrote:
|
|>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. 
|   ...
|>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.
|
|Bill Ogden replied:
|
|The issue is not that reference semantics are inherently a bad thing any
|more than that dynamite is an inherently bad thing. Neither, however, is
|intended for every day or casual use. The problem is that building classes
	      ^^^^^^^^^    ^^^^^^	- see below
|which force clients to use operations like Top that just return a reference
|to a stack entry is rather like building hardware stores which supply
|customers with sticks of dynamite whenever they ask for something with
|which to remove a tree from their lawns. If clients are careful or lucky
|they achieve their objectives. If not, you're left with a bloody mess.
|
|There's no problem with using multireference objects (or dynamite) and
|passing out references with a Top operation, if you like. The problem
|is with making this the normal rather than the exceptional way of
|doing business.

We clearly have a fundamental disagreement.  I would be interested to hear if
you can quote any case histories to support your view - i.e. where programmers
have implemented a design in a language where reference is the default (and
presumably therefore well supported), and screwed up as a result.

I confess that I can't do likewise for my own point of view, since our use of
Eiffel is currently confined to a small team, where we are building a toolkit.
I have not found Eiffel's default reference semantics create any unpleasant
problems personally, but perhaps that is because I am particularly aware of
what is going on.  I am genuinely interested in this issue, since at some point
our toolkit is going to be in "everyday use" by less experienced programmers
(although I don't think any proper software project should ever treat
programming as "casual").  Am I heading for trouble?

Pointers in C do cause problems, and we have the experience of that, but it is
very easy to make a lot of mistakes in C with pointers because the language
doesn't help you handle them properly.  References in an OOPL are a whole
different issue.

What about Smalltalk?  I only have a very limited knowledge of it, but does it
not generally employ reference semantics?  Of all languages, its object model
is probably least obvious, so if reference semantics are going to lead to
problems, I would expect it to be apparent in Smalltalk.  Can any experienced
Smalltalk users comment on this (I am widening this thread to comp.object for
this reason).

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