RE: [PHP] or return problem

On 08 October 2003 17:20, Chris Shiflett wrote: > > The internals developers probably didn't see a need to provide > > support for "return" in conditionals since it can't return a value > > to the conditional. > > Ugh. This is the same misconception, again. Let's try some different > code: > > <? > function foo() > { > echo "foo\n"; > } > > function bar() > { > return true; > } > > bar() or foo(); > > > > > The return of foo() does not matter. It is not evaluated. Semantically, that is true -- but syntactically it still has to *have* a potential value (since bar() *might* return false), so PHP will barf at the compilation stage if instead of foo() you have a construct which *cannot* return a value. The distinction is not whether the construct on the right of "or" is actually executed or not for any given combination of input values, but whether it is *capable* of returning a value, should it be called upon to do so. > I do not > understand why this is still unclear. Consider this: > > if (!bar()) > { > foo(); > } > > Does it seem like foo() is involved in the conditional when expressed > like this? I hope not. No -- but expressed like this, foo() is not required to have a return value -- it only needs to be executable. In bar() or foo() it must actually be *capable* of returning a value, even if that value can never be used. In short, it's a compile-time question ("can this construct return a value if required to do so?") vs a run-time question ("does this construct need to be evaluated?"). Cheers! Mike --------------------------------------------------------------------- Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: m.ford@lmu.ac.uk Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211