W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2002

Re: DOM L3 XPath question

From: Vivek Pandey <Vivek.Pandey@Sun.COM>
Date: Tue, 06 Aug 2002 17:35:31 -0700
To: Ray Whitmer <rayw@netscape.com>
Cc: www-dom@w3.org
Message-id: <3D506B53.7070102@sun.com>

Hi Ray,

Thanks for clarifying it!


Ray Whitmer wrote:

> Vivek Pandey wrote:
>> Ray Whitmer wrote:
>>> It means that the evaluate method may reuse the result parameter as 
>>> the result object.
>> Thats what i understood from the spec. But i am not finding info on:
>> * How does result object passed as parameter be reused by the 
>> evaluate function? I mean can it be used by the application for 
>> iterative evaluation?
>> * Is the *reuse *of result object is implementation dependant?
>> * In *Issue XPath-30*, the Resolution says for some use case it may 
>> be required. Is there anywhere i can find more info?
> * The purpose of reuse of XPathResult is that, for efficiency, your 
> implementation may be able to reuse a previously-created object 
> instead of creating a new one.  A number of implementers thought this 
> was important.  Others thought it was not important.
> It is implementation-dependent whether the evaluate method reuses and 
> returns the passed-in XPathResult (if any) or creates a new one.
> In the official last-call issues list for DOM Level 3 XPath, there is 
> no Issue-30.
> The use case for which people want to use it is the one described 
> above, that I marked with *.  For example:
> var result = null;
> var i = 0;
> for (i = 0; i < e.length; i++) {
>  result = e.evaluate(expression[i], mynode, 0, resolver, result);
>  [...]
> }
> In this type of a loop, an implementation that can easily reuse a 
> result object would only create a single result instead of creating 
> one every time evaluate was called.
> An implementation is free, however to reuse all, some, or none of the 
> results passed to it.  In some implementation, therefore, result would 
> be a different object each time the loop was executed.  Or an 
> implementation may choose to only reuse the result when the resultType 
> was the same, etc.
> If we are not going to rely on normal deallocation / allocation every 
> time, the application is the only one to know when the result might be 
> reused, which is why the application has to pass it in as a parameter 
> for reuse for implementations to reuse it if they so choose.
> I hope that this is helpful.
> Ray Whitmer
> rayw@netscape.com
Received on Tuesday, 6 August 2002 20:33:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:56 GMT