References (was: Re: Is garbage collection here yet?)

Neil Madden <nem@cs.nott.ac.uk> wrote:
>> more palatable if they weren't strings which could be decomposed
>> (hiding the reference) and then recomposed later.
>
> Yes and no. Having strings which can't be decomposed would be useful to
> avoid cases where someone splits up a reference and then puts it back
> together and wonders why their object has been collected.

So, the problem with references is, what happens, when
they are converted to string.

 A) trying to convert a reference to a string could
    throw an exception.
     Pro: any unintended stringification would be
            immediately detected where it happens,
            instead of when the referenced Object
            is suddenly gone at some later time.
     Con: Stringification just "happens" sometimes,
            likely in foreign modules, where one cannot
            really solve the issue.

 B) Upon stringification (but *only* then!), a named reference is
    autocreated.
     Con: leakage possibly (though not as generally) re-introduced.
     Pro: no unexpected "loss" of objects. For known paths of
         stringification the named reference could be "manually"
         removed lateron, re-enabling automatic object management.

This would cover the non-cyclic referential object structures.
Many of the needs mentioned in the GC-thread might already be
satisfied at that stage.
Anyone who then tries to use the references as in Java, will
still suffer memory leaks.
There probably also exist ways to enhance ref-count based GC to
deal with cyclic structures, but I'm not sure how sound they
are.
Received on Sun Apr 30 02:41:09 2006