[
Lists Home |
Date Index |
Thread Index
]
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.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
