On Wed, August 24, 2005 6:10 pm, Jordan Miller wrote:
Is there a technical reason why PHP does not allow comparison
operator expressions like the following:
if (2 $x = 4) {}
2 $x = 4 is a valid expression already.
2 $x is evaluated first, and returns true/false
true/false is compared with 4 using = and will always return TRUE,
since true/false will get typecast to 0/1 in order for the comparison
to be made.
At least, I THINK that's what will happen... Not sure on the
type-casting of something that I'd never code in the first place.
At any rate, it's already valid under current syntax, so you'd have a
HUGE backwards incompatibility issue to change it.
From what I can tell, this expression can currently only be written
as:
if ( $x 2 $x = 4) {}
I personally would use:
((2 $x) ($x = 4))
Yes, the extra parens are kinda bogus -- But they visually separate
the two tests.
Putting the 2, $x, and 4 in order is similar to the 2 x = 4
Algebraic notation.
It wouldn't bug me to see 2 $x $x = 4, mind you.
In code I've read/written, it's seldom been a real problem.
In fact, if the author is CONSISTENT in their ordering, and SYSTEMATIC
in their tests/conditions/expressions, it doesn't even really matter
to me if they use 2 $x $x = 4 or $x 2 $x = 4, so long as
it's the same way in all their code.
Would adding this syntax to PHP be incredibly difficult or lead to
performance slowdowns?
Probably not incredibly difficult, per se, and performance would not
suffer in any measurable way...
You'd just break a few zillion existing scripts that, whether the
authors know it or not, rely on the current behaviour.
I suspect it would also unearth a large number of previously
un-noticed bugs :-)
I think I remember reading that PHP always evaluates expressions from
right to left,
If you did read that, it was a REALLY BAD thing to have been written
by anybody anywhere. :-)
[Maybe that goof that decided PHP wasn't ready for Enterprise use we
were discussing a couple days ago. He was great at writing FACTUALLY
INCORRECT statements to shore up his pathetic arguments. :-)]
PHP has a very precise order of operations with Operater Precedence:
http://php.net/manual/en/language.operators.php#language.operators.precedence
In fact, some of those are VERY common pitfalls for newbies.
|| versus AND OR often trips up beginning scripters.
Not only does PHP not always evaluate from left-to-right due to
precedence, even within the precedence ordering, some operators are
right-to-left associative:
$x = 2;
$y = 5;
$x = $y = 3;
Here we have a tie in order of operations between two assignment
operators.
Since = is RIGHT associative, the tie-breaker is to read from RIGHT to
LEFT and do the operations in this order:
$y = 3;
$x = $y;
So both $x and $y are 3.
[WRONG]
If = were LEFT associative, which it's NOT, you'd end up with $x being
5 and $y would still be 3:
$x = $y;
$y = 3;
[/WRONG]
'Course, $x = $y = 3; is probably Bad Practice anyway...
Though I guess I've seen:
$x = $y = $z = 0;
at the top of enough functions to understand and accept that it's a
convenient way to initalize all three variables to 0...
I don't LIKE it, but I can live with it.
so I guess there may be a considerable codebase change
required. Maybe there could be a default function workaround for this
or some other way to automagically process these more concise
expressions without too much of a slowdown?? Just curious.
You could maybe check with PHP-Internals to see if they believe that
nobody's relying on the current behaviour with = =, and then
there's no problem adding it, but I wouldn't get yer hopes up.
PS Is (2 $x = 0) a syntax error, or would you allow that silly
expression? :-)
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
