Path: utzoo!attcan!uunet!mcsun!ukc!cam-cl!scc
From: scc@cl.cam.ac.uk (Stephen Crawley)
Newsgroups: comp.sw.components
Subject: Re: List ADT example
Message-ID: <917@scaup.cl.cam.ac.uk>
Date: 27 Sep 89 09:07:57 GMT
References: <915@scaup.cl.cam.ac.uk> <6590@hubcap.clemson.edu>
Sender: news@cl.cam.ac.uk
Organization: U of Cambridge Comp Lab, UK
Lines: 74

I wrote:
>> First objection: I don't want to put a copy of the instance of A into 
>> the list twice.  I want to put the SAME instance of A into the list 
>> twice.  If A is a mutable type (i.e. has operations that can change 
>> a value) this is a significant semantic difference.  

Bill Wolfe replies:
> Then what you want is a list of pointers, not a list of objects.

Huh???  Since when has it been a property of an object that I can only
have one reference to it?  You see to have a particularly restricted
idea of what an object is!  

No Bill.  Given normal use of the term object == instance of an ADT, I 
want what I said I want ... the ability to put the same object into 
a list twice.

Alternatively, if you insist that I use a different generic list ADT 
(say POINTER_LIST), please explain how it does storage management 
without pushing the tricky part (in particular the decision about when
reference counts should be incremented or decremented) back to application
code.  

I wrote:
>> I can't see how the application is forced to call DESTROY on an A
>> variable when its declaration scope exits.  

Bill replies:
> As mentioned above, the ADT creates and destroys on its own with
> respect to the stored object.

Yes Bill ... I understood all of that ... and I understood the mechanism
that ADA uses to force the application to cooperate in most cases.

> As far as the ADT's destruction
> goes, the automatic destruction upon scope exit is not a part of
> Ada 83; it is presently being considered as an Ada 9X revision. 
> This revision will greatly improve the ability to specify and
> use components which manage their own space.

But my point is that the mechanism doesn't exist NOW.  Given that it
is being CONSIDERED for Ada 9X, it is a safe bet that it won't be 
available in production Ada systems for at least 3-5 years.  What
do we do to till then?  Use inferior software components that can't
get space management right for us?

---

I sketched the code for a LIST ASSIGN operation and pointed out that
the reference counting overheads would in many situations be higher 
that the overheads of GC.

Bill Wolfe replies:
> Try writing the assignment procedure without reference counting,
> since nobody ever does reference counting inside assignment anyway...

The generic list ADT problem that I outline requires that SOMETHING 
does reference counting.  It is a direct consequence of the stipulation 
that the generic list must allow instances of an ADT to appear in a list 
more than once.

Now you have been insisting all along that our generic list ADT and our 
list member ADT (say A) can between them deal with all of the storage 
management decisions associated with instances of A.  Clearly we cannot
expect the application to be explicitly involved in reference counting.
In ADA, this means that the ASSIGN operation must do it.  There is no
other option as far as I can see.

Bill if you are going to contradict me on this, please post the complete
ADA source code of the generic list ADT and another ADT that can be used
to instantiate the list.  Be sure it solves the problem as I've specified 
it ... not some trivialisation.

-- Steve