Re: Extension candidates

Dimitre Novatchev wrote:
> 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.

That's not really true. The fact that nothing changes is an illusion 
that the language environment plays on the program by carefully managing 
it's access to the outside world (disk, network, etc.). It's entirely 
possible that an XML file on disk could change during the time a program 
is running.

John

-- 
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:            http://oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net