Issue Xpath-30: Reusing result sets

From the draft:
>Issue XPath-30: 
>Eliminate the reusable result argument.
>Resolution: No change.
>No. We have use cases for it, and there is already an implementation
showing there >is nothing wrong with it. 

At least, I would like to have the wording changed on the description of the
result argument.  It currently reads:

The result specifies a specific XPathResult which may be reused and returned
by this method. If this is specified as null or the implementation cannot
reuse the specified result, a new XPathResult will be constructed and
returned.

The problematic part is "cannot reuse" since that implies that
implementation must try to reuse the result set even if the implementor
knows that reusing the argument is going to be more expensive than creating
a fresh result object.  The description should be worded so an
implementation is completely free to disregard the result argument.

I was hoping that another person who also commented on this method was going
to benchmark any difference in performance between reusing a result set and
passing null consistently.  My instinct is that any performance gain is
negligible.

Received on Thursday, 28 March 2002 13:09:42 UTC