Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21886
Return-Path: <andi@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 46804 invoked by uid 1010); 16 Feb 2006 21:57:06 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 46789 invoked from network); 16 Feb 2006 21:57:06 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 16 Feb 2006 21:57:06 -0000
X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4)
Received: from ([80.74.107.235:58599] helo=mail.zend.com)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id C5/F2-27865-135F4F34 for <internals@lists.php.net>; Thu, 16 Feb 2006 16:57:06 -0500
Received: (qmail 26917 invoked from network); 16 Feb 2006 21:57:00 -0000
Received: from localhost (HELO ANDI-NOTEBOOK.zend.com) (127.0.0.1)
	by localhost with SMTP; 16 Feb 2006 21:57:00 -0000
Message-ID: <7.0.1.0.2.20060216134358.05a08240@zend.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Thu, 16 Feb 2006 13:56:59 -0800
To: "Sara Golemon" <saramg@berkeley.edu>,"Zeev Suraski" <zeev@zend.com>
Cc: <internals@lists.php.net>
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: andi@zend.com (Andi Gutmans)

<DISCLAIMER>
I am not a big fan of operator overloading because after years of C++ 
development I came to the conclusion that the syntactic sugar it 
provided was not worth the debugging hours lost due to hidden magic 
happening. It actually makes it hard to understand certain code when 
you're just reading it then explicitly calling the methods like in 
Java, something like obj.equals(2).
</DISCLAIMER>

Anyway, I think this case has some other issues. How would you treat 
2 < $obj. Wouldn't you want to call $obj->__is_greater(2)? Actually 
my suggestion would be to not make it left associative but to require 
a consistent design. If you have $obj1 < $obj2 then I don't think it 
has to be defined which one gets called or whether __is_smaller or 
__is_greater is called. If either of these are overloaded, it should 
know how to deal with objects that can compare with it (possibly via 
interface, etc..) and with objects that it can't compare to (possibly 
always returning false, etc...).
So I suggest to create the following behavior:
$obj < 2 - Calls $obj->__is_smaller(2);
$obj > 2 - Calls $obj->__is_greater(2); (figures our that 2 isn't 
overloaded so checks $obj)
$obj1 > $obj2 - Can call either depending on which one implements the 
overloading.

In any case, if at all, I think the right thing would be to have an 
IS_GREATER opcode and not an extended_value hack. But as I said, I 
don't think operator overloading should be part of standard PHP so I 
think making such changes does not make immediate sense.

We could possibly split that into two opcodes for PHP 6 mainly as a 
"documentation" feature of the source code so less is lost during the compile.

Andi


At 09:55 AM 2/16/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