- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 17 Jun 2007 21:45:26 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4446 ------- Comment #5 from hrennau@yahoo.de 2007-06-17 21:45 ------- (In reply to comment #2) 1. "unless that branch is selected" =================================== > * Conditional and typeswitch expressions ... must > not return the value delivered by a branch unless that branch is selected. Please check my understanding: is this equivalent to stating that "if the conditional expression as a whole is evaluated, the condition MUST be evaluated"? In other words, what does it exactly mean that a branch has been *selected*? I guess (and hope) it means that the branch in question has been selected by evaluating the condition. (How else?) But it seems to me the present wording might still leave room for uncertainty. For example, one might start to wonder if > if (...some external function call) > then true() > else true() might be rewritten simple as true() arguing that in this case one at least has not returned the result of a branch that has *not* been selected... Probably a fallacious argument, but at any rate I suggest a wording that explicitly demands the evaluation of the condition. Or have I misunderstood your intention? 2. "semantics of conditional expressions" ========================================= > Other than the raising or not raising of errors, the result of evaluating a > rewritten expression MUST conform to the semantics defined in this > specification for the original expression. Concerning condition expressions, I wonder if the intuitive order of execution - first the condition, then the selected branch - is part of the semantics which are protected by the new wording. The spec 3.10 Conditional Expressions says: "The first step in processing a conditional expression is to find the effective boolean value of the test expression, ..." So, to frame my question into a concrete testcase: could the expression if (java:openBase ne true()) then java:recoverOpenError() else true() be rewritten this way: let $res := java:recoverOpenError() return if (java:openBase ne true()) then $res else true() I hope it cannot, that is, I hope the execution order "condition first, branch second" is guaranteed, as this leaves to the query writer one of the last possibilities to control sequence...
Received on Sunday, 17 June 2007 21:45:28 UTC