RE: Issue Xpath-30: Reusing result sets

> On Thursday, 03/28/2002 at 01:11 MST, "Arnold, Curt" 
> <> wrote:
> > The second concern is that allowing reuse makes it unsafe to provide
> access
> > to a result set that is part of the state of an object
> No different from any other mutable object, right? If this is 
> a concern for the user, s/he passes in null and obtains a new 
> instance. If they _know_ they can safely reuse, they do so.

The potential for reuse does make any XPathResult effectively mutable and so
would suggest that any public method that would return an XPathResult return
a defensive copy of its state and not the XPathResult that it holds (per
item #18 or so in Effective Java, I need to order another copy).  The same
way that you would return a clone of an array instead of the array itself to
prevent a careless or hostile caller from changing an object's state without
the object's participation.

Unfortunately, there is not an easy way to create a defensive copy of an
XPathResult short of evaluating the query again, which could be expensive or
wrapping the result in a read-only wrapper, which is an pretty advanced

Relying on the caller to honor its contract not to reuse the XPathResult
that you returned could be prone to failure.  For example, if there were
code like:

XPathResult result;
while(something) {
   if(cond1) {
     //  result is safe to reuse
     result = xpathEval.evaluate(...);
   else {
     //    result is not safe to reuse
     result = myFoo.getBarElements();
   //  much later code, could dork myFoo
   result = xpathEval.evaluate(...,result); 

Providing a mechanism to clone a result set would probably be a better
solution than the canAllowReuse that I mentioned in the earlier message.  If
an implementation knew that its XPathResult was immutable, it could just
return "this", otherwise it could do some lightweight copy of the

Received on Thursday, 28 March 2002 18:24:17 UTC