RE: [dom-xpath] Competing Proposals Proposal

scott 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.

The choice of using a stack, in my opinion, should be a choice made by the 
implementor not the interface. Replacing a variable is a kludge in case of the 
stack. Besides how would you make that thread safe ?



> 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.

+1 I agree, that's a nice feature which can easily be solved in my setup by 
adding a "setVariableList( VariableList aList )" on an expression.


> 
> > variables.addVariable( new Variable("a","b") );
> 
> What advantage does the Variable class add?  Can you give an example?

Not too many, you might be able to share them among variable lists, it could be 
a node, it can be extendable for different/future expression modules, it's a 
natural "object" and should therefore have an interface.

Best Regards,

Jeroen

Received on Saturday, 13 May 2000 09:11:43 UTC