Re: About node references

> > I realize that until now I have presented this idea only very
> > vaguely. Here is a first try at a more consistent presentation.
> 
> > A "Ref" is an object that has two parts: a reference (memory
> > reference) and an associated string key. So, a Ref can be
> > represented by the pair:
> 
> > [...]
> 
> > Also, when all Refs to an item are destroyed, this item can be
> > garbage-collected, thus no "leakage" is to occur due to using Refs
> 
>   I must admit I am a bit lost.  If items can be garbage-collected
> when there is no more Ref "pointing" to them, what's the point to
> have a copy function?

The point is to give a new Ref to someone else, so they will be able to deref it, even thow the original Ref has been destroyed. That is, to ensure that the item will *not* be garbage-collected. Or, to quote the original message once again:

"Additionally, we have the function:

  Ref       xx:copyRef(Ref ref1)    From an object ref1 = (strKey1, memRef1)  produces an object ref 2 = (strKey2, memRef2), such that memRef2 = memRef1

The important thing here is that we have created a second memRef to the same item. If now ref1 goes out of scope and is destroyed, ref2 may still be in scope and thus its memRef will ensure the item being referenced is not going to be garbage-collected."

The last sentence above answers your question.

>  And if the Ref object must be kept to ensure
> it is still dereferenceable, what is the string used for?

The string represents uniquely the Ref object. It can be stored as a text node and carried arround. We can deref() it:

  xx:deref(xx:getRef(strKey))

and get to the original item or sequence that was ref-ed.


As we can see, it is not at all necessary to use a higher order function in order to be able to implement a reference in XPath.


Cheers,
Dimitre