Re: Multiple Inheritance in Ada 9X/Pointers?

[pauld@beaver.cs.washington.edu (Paul Barton-Davis)]

In article <1992Jan8.225611.3226@cis.ohio-state.edu> weide@elephant.cis.ohio-st
ate.edu (Bruce Weide) writes:
>In article <kmmlhbINNmqt@agate.berkeley.edu>
>hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
>>
>> [... stuff about pointers and go-to statements ...]
>>
>>Here, likewise, the more interesting topic is "what dynamic data types
>>SHOULD we use for applications where we now use pointers?"
>>
>
> [ ...]
>
>To give you an idea of a possible approach to answering Paul's
>question, consider a list ADT.  This is an example of a "dynamic data
>type" where most people now use pointers.  The problem is not so much
>that pointers are involved in the representation of a list, but that
>the functional specification of the list ADT usually lets these
>pointers "stick out" so the client has to be aware of them.  (This is
>true even for list designs in languages that don't inherently involve
>pointers; e.g., consider Booch's list package for Ada.)
>
>What I'd argue for is that, if pointers must be used in the
>representation of some abstraction, then at least this fact should not
>be discernible to the client of that abstraction.  If this is possible
>(it is), then the uses of pointers may be buried deep in the bowels of
>a software system, where (perhaps) they can be kept under control.

I don't buy this for one moment. This whole concept is grounded in the
notion that you can partition software systems into "internals" and
"externals". Its true that if you choose carefully when you design the
interface to the "internals", you will affect the "externals",
hopefully for the better. However, IMHO it is totally absurd to
suppose that you can divide software into "places that are OK to use
pointers" and "places that are not". 

-- paul



-- 
"Been there, done that
 Been there, don't wanna go back"
				John Cale & Brian Eno, "Wrong Way up"