Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21888
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060217005156.0b12d660@zend.com>
Date: Fri, 17 Feb 2006 00:55:03 +0200
To: "Sara Golemon" <saramg@berkeley.edu>
Cc: <internals@lists.php.net>,"Andi Gutmans" <andi@zend.com>
In-Reply-To: <000901c63322$20b5d550$5c8be5a9@ohr.berkeley.edu>
References: <002201c6331d$a79473b0$58d01a44@stumpy>
	<7.0.1.0.2.20060216192615.099c9598@zend.com>
	<000901c63322$20b5d550$5c8be5a9@ohr.berkeley.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: Minor engine patch to facilitate PECL/operator
From: zeev@zend.com (Zeev Suraski)

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