Xref: utzoo comp.lang.eiffel:1641 comp.object:3683
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!seal.cis.ohio-state.edu!ogden
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Reference Semantics
Message-ID: <133154@tut.cis.ohio-state.edu>
Date: 11 Jun 91 19:15:07 GMT
References: <1178@tetrauk.UUCP> <131691@tut.cis.ohio-state.edu> <1181@tetrauk.UUCP>
Sender: news@tut.cis.ohio-state.edu
Followup-To: comp.lang.eiffel
Organization: The Ohio State University, Department of Computer and Information Science
Lines: 25

In article <1181@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
   ...
>Pointers in C do cause problems, and we have the experience of that,

(Yes, and the safety problems with nitroglycerin made dynamite a welcome
discovery too. :-)

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

Somehow I'm getting this deja vu sensation that we're back in the late 60's
discussing Go To's. One side is saying that Go To's (object references) have
an excessively complex semantics which can easily lead to programming errors.
On the other side, a few people concede that computed Go To's (C pointers)
might be a problem. However, most argue that since the jump instruction
(pointer) is essential for low level programming (basic data structuring),
it must be retained, perhaps slightly syntactically sugared, as a central
feature of high level programming structuring (reusable object design).


--

/Bill