Re: Minor engine patch to facilitate PECL/operator

From: Date: Thu, 16 Feb 2006 22:55:03 +0000
Subject: Re: Minor engine patch to facilitate PECL/operator
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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


Thread (19 messages)

« previous php.internals (#21888) next »