Morten wrote: > John wrote: > > such path. I have noticed that the absence of the > > call to resetPosition() in reset() caused a cloned > > TypedChildrenIterator to have a different state > > (namely, _position was out of sync - if it matters). > > > > TypedChildrenIterator: return this; > > UnionIterator: return(this); > > This does matter. Well spotted. I'll update the code > in these two nodes as needed (by adding the call to > resetPosition()).
Does it matter the same for the _source and _iterator objects? Just wondering, since most implementations of setMark don't preserve _position which causes BasisLibrary.countF to trash StepIterator._iterator._position. john
