[
Lists Home |
Date Index |
Thread Index
]
Bah, you're right of course. Good illustration of why I should stay out of this thread until I have enough time to properly consider my contributions. I'm not at all sure what I was thinking of.
> Uche wrote:
> > I agree with most of your post Jeni. The one thing that would be
> > nice to see introduced into XPath is some sort of shortcutting in
> > certain operators (either the boolean operators, or with an
> > introduced ternary operator). XPath 2.0's if expressions provide
> > this. If course, short-cutting is really much nicer and safer in a
> > side-effect-free language, so XPath 2.0 manages to chuck this
> > advantage as well.
>
> "Shortcutting" means that you only evaluate the first part of the
> expression if you can determine the result of the expression, correct?
> In XPath 1.0, 'and' and 'or' are shortcutting:
>
> An or expression is evaluated by evaluating each operand and
> converting its value to a boolean as if by a call to the boolean
> function. The result is true if either value is true and false
> otherwise. **The right operand is not evaluated if the left operand
> evaluates to true.**
>
> An and expression is evaluated by evaluating each operand and
> converting its value to a boolean as if by a call to the boolean
> function. The result is true if both values are true and false
> otherwise. **The right operand is not evaluated if the left operand
> evaluates to false.**
>
> I hadn't noticed that this changes in XPath 2.0 (it's not listed as
> one of the incompatibilities):
>
> The order in which the operands of a logical expression are
> evaluated is implementation-dependent. The tables above are defined
> in such a way that an or-expression can return true if the first
> expression evaluated is true, and it can return the error value if
> the first expression evaluated contains an error. Similarly, an
> and-expression can return false if the first expression evaluated is
> false, and it can return the error value if the first expression
> evaluated contains an error.
>
> Basically, implementations are free to implement it as a shortcut, or
> free not to. Which means that anyone who has taken advantage of the
> shortcutting in XPath 1.0, or who takes advantage of the shortcutting
> available in a particular implementation of XPath 2.0, is likely to
> run into problems. For example, if someone has:
>
> function-available('my:boolean-function') and my:boolean-function()
>
> then they might now get an error where they didn't before. If someone
> has:
>
> *[simple-filtering-expression or complex-filtering-expression]
>
> then their performance might be hit.
>
> I agree completely that something similar to the if expression in
> XPath 2.0 is required. I don't like if/then/else because it encourages
> people to use XPath 2.0 as a language in its own right, but I'd rather
> have that than no conditional expression at all.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
The Languages of the Semantic Web - http://www.newarchitectmag.com/documents/s=2453/new1020218556549/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
|
