I understand. Aren't you slightly worried about the implications of
making it possible for x>y to have a different meaning than y<x?
In languages where operator overloading is supported, it comes hand
in hand with strict typing, which wouldn't allow for different values
for x>y and y<x...
Zeev
At 19:55 16/02/2006, Sara Golemon wrote:
> >Enter PECL/operator, which tries to implement operator overloading
> >for objects (and does a decent job at that). In the interrest of
> >ease of use and consistency, every overloaded binary operator is
> >[meant to be] left associative. This is, in the expression expr1
> >op expr2 expr1 gets to decide how it will combine-with/compare-to
expr2.
> >
> What does it mean that it gets to decide? If it's left associative,
> then it's evaluated from left to right, no?
>
Yes, and that's the problem. $a > $b *isn't* read by the current parser as
$a > $b, it's read as $b < $a.
For all normal PHP comparisons, the distinction is unimportant... 4 < 2
and 2 > 4 will both evaluate to false after all.
However, the way object operator overloading is being done is: If the first
operand is an object implementing an overload method for this op, dispatch
to that method rather than using the tranditional comparison function. e.g.
$a < $b turns into $a->__is_smaller($b).
Now say you've got that expression the other way around: $a > $b. What
you'd expect is that if $a is an object, it'll try to call
$a->__is_greater($b). What you get is an automatic reversal of the
expression by the engine: $b < $a, which turns into: "If $b is an object,
dispatch to $b->__is_smaller($a);" which is not the same thing.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
