Re: Minor engine patch to facilitate PECL/operator

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