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 compile without some fixups).
>
> In the 'AllOrNothing' case: line 67 casts, resets and reinitializes the
> iterator that was passed on the stack. For this test-case the reset() has
> basicly no effect since it is followed immediatly by setStartNode(int).
>
> When the iterator is constructed [1] and passed 'by value' (it all happends
> on line 148) things work fine.
>
> But when the iterator is constructed [1] (line 124) and passed 'by
> reference' (line 137) it is cloned first. This cloning changes the codepath
> for StepIterator::setStartNode(int) so that it can't be reinitialized after
> the reset in line 67. Unable to be reinitialized, the iterator can't walk
> through the context nodes that are specified by the outer for-each.
>
> So, where's the bug?
>
> 1) Should clones should be reinitializable? If they are deep copies perhaps
> it wouldn't be a problem.
> 2) Should setStartNode(int) always be called after a cast? In loops all you
> need is to is reset() iterators from earlier scopes - no?
>
> Other things would need to be thought out before getting rid of clones: like
> what is the dependency between clones and when the compiler generates calls
> to setStartNode(int)?
>
> My feeling here is that iterators should be initialized once (in their
> creation context) and only ever be reset. Being able to reinitialize them in
> different contexts makes me feel a bit queasy. Always trying to reinitialize
> them in every context and relying on their runtime state to
> do-the-right-thing makes me very suspicious. For this test-case I'm thinking
> of ForEach::translate(...) calling Expression::startResetIterator(...) to
> generate the code to perform the call to setStartNode(int).
>
> In a way, this problem has already passed-by-us before: bug#2468 had a
> similar problem that you resolved with a typecheck in
> ForEach::translate(...) around the abovementioned call to
> Expression::startResetIterator(...). Your patch works when the select is a
> referenceVar but not when the select specifies a nodeset possibly
> constructed using a referenceVar. Would the latter be possible with more
> compile-time analysis? My feeling is that it is not possible.
>
> If the nodeset is being initialized at construction time with reset()
> referenceVars, why bother to call setStartNode(int)?
>
> Can I relate my wish-list?
> - rip-out setStartNode(int)
> - make reset deep
> - make all clones deep (and ensure they do a reset)
> - remove the relationship between _isRestartable and clones
> - allow initialization only via the constructor (pass current node as a
> param)
> - don't clone iterators as they are passed through the stack
> - finally, do clone iterators when they are used in the construction of
> other iterators. As in:
>
> nodeiterator = new CurrentNodeListIterator(
> // remove .reset(): let clone do the work
> // remove .setStartNode(i): i may be the wrong context
> // add clone(): so CurrentNodeListIterator has it's own clone of object
> BasisLibrary.referenceToNodeSet(object).clone(),
> true, new Param_Forwarding$1(), i, this
> ).setStartNode(i);
>
> instead of:
>
> nodeiterator = new CurrentNodeListIterator(
> BasisLibrary.referenceToNodeSet(object).reset().setStartNode(i),
> true, new Param_Forwarding$1(), i, this
> );
>
> And obivously all the compiler changes to support this....
>
> cheers,
>
> john
>
> [1] when AbsoluteIterator::setStartNode(int) is called on a non-clone it
> returns a StepIterator object. It is this object that is passed as an
> agument on the stack. If behaviour can be explaned to be I would be left
> greatly in your debt!
>
> > -----Original Message-----
> > From: Morten Jorgensen [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 19, 2001 11:28 AM
> > To: John Howard
> > Subject: Re: DO NOT REPLY [Bug 3238] - context dependent
> > initialization
> > problems with xpaths
> >
> >
> > Hi,
> >
> > Of course, I would only be deligthed to get some help & input.
> > Do you still think it is related to some badly implemented
> > iterator? I think you might be right. I find it very strange
> > the the output is correct in the first 'ByReference' test,
> > where the /data/point iterator is wrapped inside a variable,
> > but is incorrect when the iterator is passed directly to
> > the other template.
> >
> > The source of this problem could also be in the parameter
> > implementation. A variable will, if it contains an iterator,
> > reset that iterator every time it is read (even if it is
> > wrapped inside a parameter). I am not sure if parameters
> > do the same - but they should.
> >
> > Morten
> >
> >
> > John Howard wrote:
> > >
> > > Hello again,
> > >
> > > I received the following this morning (see below). Being
> > available again to
> > > look at xsltc I'm wondering if I could collaborate with you
> > to work on this
> > > bug.
> > >
> > > cheers,
> > >
> > > john
> > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, September 19, 2001 8:09 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: DO NOT REPLY [Bug 3238] - context dependent
> > initialization
> > > > problems with xpaths
> > > >
> > > >
> > > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > > > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3238>.
> > > > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > > > INSERTED IN THE BUG DATABASE.
> > > >
> > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3238
> > > >
> > > > context dependent initialization problems with xpaths
> > > >
> > > > [EMAIL PROTECTED] changed:
> > > >
> > > > What |Removed |Added
> > > > --------------------------------------------------------------
> > > > --------------
> > > > AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
> > > >
> >
>
> --------------------------------------------------------------------------------
> Name: Param_Forwarding.java
> Param_Forwarding.java Type: unspecified type (application/octet-stream)
> Encoding: quoted-printable
