Re: Keys are references, too (was Re: Garbage Collection)

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <1407@trantor.harris-atd.com>, by bbadger@x102c.uucp (Badger BA 64810):
> Mr. Wolfe does not (here) recognize the social security number (SSN) as 
> another form of access mechanism.  *Any* means by which a symbol can be 
> introduced to stand in as the ``name'' of the actual object will introduce 
> the ability to ``share'' the object by mentioning the name in two places.  

    If I have an object A, and pointers to that object P1 and P2, then
    I have three distinct objects, none of which share structure.

    If I have objects B and C, such that a modification to B results also
    in a modification of C, then this is structural sharing.  

> Another key thing that Mr. Wolfe does not address is the problem of deciding
> *when* to destroy an object.  Sure, it's easy enough, in most cases, to write 
> a destruction routine, but you can't always wait until passing out of the 
> scope of the visibility of the ADT to clean up.  

    This is why users can explicitly call DESTROY when the object is 
    no longer needed.

> Mr. Wolfe's database design has the 
> same problem:  It's easy to remove the personnel record, but you may only 
> do so when the SSN is not referenced any more.  

    Not true.  If the SSN refers to a person who is dead, then that fact 
    can be delivered as the database's response.  If the SSN refers to a
    person who has been deleted from or never existed in the database, then
    this can be delivered as the database's response, perhaps by raising an
    exception.  The database manager must decide how keys are to be managed, 
    and users of those keys must follow the database manager's directives.

> Leaving this decision up to the clients of the ADT, say by providing explicit
> DESTROY(X) calls, just pushes this burden on the programmer of the client.  

    If the programmer wishes to maximize space efficiency, explicit calls
    to DESTROY can be made when appropriate.  The block exit mechanism
    provides a convenient mechanism by which this directive can be given
    implicitly but unambiguously, with precisely known timing.

> It seems to me that investing a lot of serious effort to 
> get a really good GC algorithm built into the language would be much better 
> than expecting "average" programmers to correctly implement proper storage 
> reclamation for each ADT they'd like to use which requires memory allocation.

    Implementing proper storage allocation is the responsibility of the
    person who designs the ADT.  I think average, below average, and
    barely-above-brain-dead programmers can all comprehend the fact that
    objects must be both created and destroyed; they are created upon 
    declaration, and destroyed either by calling DESTROY or as an implicit
    consequence of block exit.

> Even if not every compiler vender has ``the world's best'' memory reclamation,
> it will be easier to select one that does, based on professional reviews, 
> than to implement it yourself.

    OK, all those who think it's just TERRIBLE to have to actually program 
    for reuseability can *purchase* generic ADTs, a/k/a software components.

    Then you can select the components you need, based on professional
    reviews, rather than implementing them yourself.  (Satisfied?)

    Wizard Software and Lib Systems are two vendors which supply such ADTs;
    anyone considering such a purchase should seek out professional reviews,
    since I write my own ADTs and therefore I have absolutely no experience 
    with and do not in any way endorse either firm's products.

    I might add that Jean Ichbiah explicitly predicted, long ago, the
    emergence of a software components industry, based upon the generic
    features of the (then-new) Ada language.  Slowly but surely, his 
    prediction is being fulfilled.



                                            Bill Wolfe

                                    wtwolfe@hubcap.clemson.edu