RE: [dom-xpath] Competing Proposals Proposal

jeroen@tcf.nl wrote:
> I don't like the idea of the stack behind the variable list.
> Why not a simple addVariable("what", "this"), removeVariable("what") ?

Well, you have to take this from where it comes: an implementor of an XSLT
processor.  I may have several "what" variables in scope, but only the
least recently pushed wins.  If I remove the last pushed "what" variable, I
would expect the previous "what" to come back in scope.

All languages that work with variables work this way.  A use case: if I am
an implementor of XPathScript (someone has done something like this for
Perl), this is how I would want it to work.  If we do it the way you
suggest, the implementor would have to kludge their own stack, which would
be somewhat painful, I think.

>  PaxVariableList variables = expr.getVariableList();

Yep, a seperate object might be useful.  The reason I didn't go this route
in the proposal is that it feels like the XEnvironment itself is pretty
close to the PaxVariableList.

Also, the way you have it set up there, it looks like each expression has
it's own variables list.  This doesn't seem right to me... I would expect a
variables stack/list to be shared among multiple XPath expressions.

> variables.addVariable( new Variable("a","b") );

What advantage does the Variable class add?  Can you give an example?

-scott

Received on Friday, 12 May 2000 18:37:00 UTC