Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!roundup.crhc.uiuc.edu!m.cs.uiuc.edu!cs.uiuc.EDU!johnson
From: johnson@cs.uiuc.EDU (Ralph Johnson)
Newsgroups: comp.lang.eiffel
Subject: Re: Reference Semantics
Message-ID: <1991Jun11.223305.16439@m.cs.uiuc.edu>
Date: 11 Jun 91 22:33:05 GMT
References: <131691@tut.cis.ohio-state.edu> <1181@tetrauk.UUCP> <1991Jun10.215822.28034@m.cs.uiuc.edu> <133169@tut.cis.ohio-state.edu>
Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
Reply-To: johnson@cs.uiuc.EDU (Ralph Johnson)
Organization: University of Illinois
Lines: 40
Nntp-Posting-Host: m.cs.uiuc.edu

In article <133169@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
|> In article <1991Jun10.215822.28034@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes:
|>    ...
|> >Improper use of references can certainly cause problems, but
|> >improper use of anything can cause problems. 
|> 
|> Improper use of GoTo's can certainly cause problems also, but we don't
|> use them much any more. We observed that there was a problem and that
|> there were efficient alternatives, and we changed our ways.
|> 
|> --
|> 
|> /Bill

Bill, this is an annoying message.   I carefully stated that reference
semantics were often the RIGHT way to think about a problem and to
specify it.  You seem to have completely ignored the whole point of
my message, so why bother to quote it?

Perhaps C pointers are like go-tos, but object references are not.  
If you want to model a world with state then object references make
programs clearer and easier to understand.  In my opinion, the inventions
of the functional programming language community to compensate are
confusing and are unlikely to make programs easier to understand.

If you don't have references in your language then you will be forced
to simulate them.  Consider a user interface system.  It is natural to
model buttons and menus as objects with state.  Without references
you will end up with "button-id" values and a set of "pressed-buttons"
that tells you whether a button is pressed.  There will be a function
"clients" that indicates the program entities that should be notified
when the button is pushed.  Now you end up passing around button-ids 
and checking whether it is in the pressed-buttons set and notifying
its clients.  This is no different from a reference.  However, lack 
of references has caused all sorts of data to be distributed throughout 
the system instead of being encapsulated and hidden.  I claim that
this kind of a design is much worse than the natural design with
references.

Ralph Johnson