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.