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: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
