Morten Jorgensen wrote:
> We have to clone the iterator for each time the
> parameter that contains it is referenced. The
> reason why will easily show when a single parameter
> containing a node-set is referenced several places
> inside a for-each loop (or ever worse with nested
> for-each loops)
John,
We have to clone the iterator for each time the parameter that contains it
is referenced. The reason why will easily show when a single parameter
containing a node-set is referenced several places inside a for-each loop
(or ever worse with nested for-each loops):
<--- iterator rese
Well, with this fix all nodeset parameters will be cloned by the cast
operator - cloned at the time they are cast. This would appear to penalize
templates that use any passed parameters (more-so if the parameter is used
in a loop).
Instead of cloning the iterator when the parameter is cast, how a
John,
It seems like in this case the problem was not that the reset() and
cloneIterator() methods of the iterator in use was not implemented
properly. The problem was that the cloneIterator() method was not
even called in some cases. The BasisLibrary class has a static
method called referenceToNo
John,
Your analysis is very good. Some cloned iterators cannot be reset, and
causes a problem when they are passed by referenced (ie. cloned). Making
all clones deep, and thereby allowing the clone to be reset, should make
this problem go away.
But I don't like the idea of removing setStartNode(
John Howard wrote:
>
> Morten,
>
> I think I have a nice tight answer to your question about the different
> behaviours when the iterator is wrapped in a reference. I can do this by
> refering to the enclosed Param_Forward.java file which is the decompiled
> translet from bug#3238 (it won't comp
