Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!usage.csd.unsw.oz.au!syacus!ian
From: ian@syacus.acus.oz.au (Ian Joyner)
Newsgroups: comp.lang.eiffel
Subject: Re: Reference Semantics
Message-ID: <1991Jun19.001829.28317@syacus.acus.oz.au>
Date: 19 Jun 91 00:18:29 GMT
References: <1181@tetrauk.UUCP> <133154@tut.cis.ohio-state.edu> <1991Jun12.072557.7282@jyu.fi> <133644@tut.cis.ohio-state.edu>
Organization: ACUS Australian Centre for Unisys Software, Sydney
Lines: 42

ogden@seal.cis.ohio-state.edu (William F Ogden) writes:

>It's true that analogies only suggest, but don't prove. In this case,
>the analogy suggests strongly that we examine very carefully whether
>the visible use of references is really that central to object oriented 
>design. A good example or two showing where references are fundamentally
>necessary could perhaps expose the deficiencies of the proposed [dangerous?]
>analogy.

Maybe I'm missing something, but it seems to me that references are a
fundamental thing in the real world. Take networking and databases, where
shared information is what the customer wants. The user may want fast
access to some information, and therefore have their own copy, or alias.
But this has the danger that their information gets out of date. If
slightly out of date information is acceptable then this is OK. If it
is not acceptable, then the user must always access the original by
means of a reference.

As object oriented programming reflects the real world, it seems that
references will be inevitable. However, if we did not share data like
this, then all the research into concurrency would be unnecessary. I
think that in the abstract sense, that communications references 
(addresses) and OO references are the same thing. Conceptually,
they are not C pointers, although underneath they may be implemented
the same, just as conditionals, loops, etc are implemented the same
underneath as gotos, ie jumps.

Similarly in the database world, there is a lot of effort to keep a
database consistent. Again this is only a problem because it is a
common requirement to share common data. I suspect this is actually
what makes computers so useful. If it were not a requirement, we may
as well not have data bases or data communications at all. But then
my life would be much simpler!
--
Ian Joyner
Australian Centre for Unisys Software
61-2-390 1328
ian@syacus.oz
-- 
Ian Joyner                                     ACSNet: ian@syacus.oz
ACUS (Australian Centre for Unisys Software)   DNS:  ian@syacus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz