Re: Extension candidates

On Fri, Dec 12, 2008 at 2:48 AM, John Snelson <[email protected]> wrote:
> Dimitre Novatchev wrote:
>> A big difficulty is
>>> the
>>> interaction with garbage collection. There are two conflicting
>>> requirements
>>> - the reference should be a string, so you can store it in a document;
>>> but
>>> the node should continue to exist so long as the reference exists.
>>> Basically
>>> these two requirements come from different use cases, and I think they
>>> might
>>> need different facilities.
>>
>> These two requirements are not conflicting. I imagine an
>> implementation where references are stored in a hash table, where the
>> string is the key and the actual reference is the value.
>
> The problem is, when can the implementation garbage collect the documents
> stored in the hash values? It would need to prove that no one was going to
> be trying to dereference a particular key - but since the keys are just
> strings (can be copied, concatenated, embedded in XML and extracted etc.)
> it's impossible to prove this. Therefore this approach basically represents
> a big memory leak.

This presents a problem only if we regard a "reference" as a memory
address. In fact a reference can be anything that uniquely identifies
the node/sequence. It may be an URI + id/XPath-expression, or a disk
address, or ...

As we are working with a functional language, all the objects that are
being referenced do not change during their lifetime. Therefore, it is
not necessary to keep them in memory all the time. Rarely used objects
can be conveniently discarded and reconstituted on-demand.

Therefore, having a reference forever does not mean having the
referenced object alive forever -- no major problem here.

Dimitre