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

Michael Kay wrote:

> I seem to be having trouble explaining this. The problem is that
> the result of the expression

> (ref($RM, $N), deref(RM, 'n123'))

> depends on the order of evaluation of the two subexpressions.

  Yes, that was my biggest concern too, as we discussed offline with
Dimitre.  Here is finally the last response I've sent to him:

|  Mmh (thinking aloud...)  And because, by specification, one is
| only allowed to call deref() with a string obtained by ref()
| (even indirectly, via an XML tree), there is a dependence between
| those calls, and an optimizer won't be allowed to re-order a
| valid deref() before its corresponding ref()...

|  Even with lazy evaluation, if the result of a ref() is not used,
| there couldn't be any valid deref() with that string.

  The key word here is *by specification*.  The drawback is that any
implementation couldn't help the developer pointing out his mistakes
regarding this point.

  That's the advantage of having a third type of item: the
implementation can check the object is actually of the expected type
(but doesn't allow to be add to an XML tree.)

  Besides the lifetime of the RM has to be handled as well, that would
prevent one to do something like:

   <xsl:function name="my:make-something">
     <xsl:variable name="rm" select="ex:make-ressource-manager()"/>
     <xsl:sequence select="ex:ref($rm, ...), .., ex:ref($rm, ...)"/>
   </xsl:function>

without having the RM passed by the caller as a param instead.  I
wonder if we are not after two different features here...?

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/