Re: References in XPath that can be represented by a string andstill can be garbage collected

> > I've read an article
> > http://www.fgeorges.org/exslt2-wiki/References_in_XPath_that_c
> an_be_represented_by_a_string_and_still_can_be_garbage_collected.
> > It seems to me that the idea of explicit "Resource Manager" 
> > object goes against the spirit of functional programming.
> > 
> > Except that I think it has technical flaws.
> > Processor has a great freedom to reorder operations.
> > This potentially may lead to dereferencing something that was 
> > not referenced.
> > 
> > I think the better way to is to introduce a map in exslt 2, 
> > and then build (unique-string, object) map to store the binding.
> > What do you think?
> 
> I think there are some ideas worth pursuing here, but I'm not 100% convinced
> they are sound.
> 
> The concept of a "resource manager" does have the merit that it provides a
> scope for the persistence of string references: they are valid so long as
> the resource manager exists, and when the resource manager ceases to exist,
> the string references are no longer dereferenceable and the nodes can be
> garbage collected.
> 
> The question marks arise because the resource manager is stateful:
> references are added to it incrementally. Therefore, in pathological cases,
> the result of
> 
> (get-reference($rm, $node), dereference($rm, 'd0'))
> 
> will depend on the order of evaluation. However, I'm not sure how much this
> matters, since it seems it can only affect the outcome if you try to
> dereference a string that didn't originally come from the resource manager,
> and the effect of doing that is always going to be unpredictable anyway.
> 
> Michael Kay

Excuse me for sleeping and not being able to see and reply. I already replied to Florent offlist regarding this concern:

"Good observation. The answer is that there is no problem. A RM can
only accumulate new resources, and when it is destroyed it destroys
all of them. It may happen that there is an attempt to add a resource
that already was added to the RM -- this results in a NoOp and is
harmless. Apart from this there are no other conflicts."

The only "writing" operation inside the RM is adding a new resource. The only anomaly here is when the resource has already been added. In this case the RM simply does not do anything (a No Op).

This fully answers the question and proves that there are no concurency anomalies.

Any other questions?

P.S. I apologize for the poor formatting of the Wiki page -- it is only a first draft and I believed nobody will see it as I didn't link it from any other page. I have almost zero experience with Wiki and would appreciate any reference to help about formatting text and source code in Wiki.