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

"Vladimir Nesterovsky" <[email protected]> Thu, 18 Dec 2008 13:09:45 +0200
Newsgroups gmane.text.xml.xslt.extensions
Message-ID <[email protected]>
> The question marks arise because the resource manager is stateful:
> references are added to it incrementally.

That's what I'm worrying about.

In many cases algorithms may be refactored into a following stages:

1. a preprocess generating references.
2. create map.
3. a postprocess using map of references.

This looks functional.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com/

>> 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.