Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67410
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.210.47 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <518FFD17.4040202@sugarcrm.com>
References: <CAF+90c_PPTajBqs636f373DKF=hotrK1ObTojddxx=bxC3g16w@mail.gmail.com>
	<518FD653.6070705@daylessday.org>
	<CAF+90c_qj9_GcqhYSBRnbYLBJ-31iBSUTdnVn8owWJxpzqRedQ@mail.gmail.com>
	<CAESVnVov7hyt=AW+XwB2z6Jf3870bJO5DcnFTb7o66FN3Ds1TA@mail.gmail.com>
	<CAF+90c9d-R9PqPAKuFLpc3yHE5sVMbTYScw1UH0jVrH5zhBaoA@mail.gmail.com>
	<518FFD17.4040202@sugarcrm.com>
Date: Sun, 12 May 2013 14:00:58 -0700
Message-ID: <CAESVnVpRPx2g1xzjBV0VZ_i3CDJT9x5ssMb6-=B8N=0b86bgfw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Antony Dovgal <tony@daylessday.org>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b67083d62840804dc8bb20a
Subject: Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
From: pollita@php.net (Sara Golemon)

--047d7b67083d62840804dc8bb20a
Content-Type: text/plain; charset=ISO-8859-1

>
> > Why would this be confusing? I'd agree if this happened in userland
> (people
> > could wonder why the operators are swapped), but internally we are
> already
> > dealing with this anyway. E.g. when you implement compare_objects you
> have
> > to be aware of this (to understand stuff like the return 1 trick).
>
> Your code suggests (even though RFC never says it) that the left operand
> defines the comparison. However, for the switched operations, the right
> operand would then define the comparison. It is pretty confusing, IMO.
>
> This.  I see in zend_object_do_operation that op1 (LHS) has priority, but
if it's not an object, then op2(RHS) gets the chance to handle it.  So it
works fine in the simple case of (Object and Non-Object), but if you have
two different Objects, both implementing operator overloading in
potentially different ways then the precedence order matters more.  By
having a separate opcode for GREATER, the user can explicitly state who
they want to get precedence.

I realize I'm potentially trying to solve a problem which doesn't exist,
but separating out smaller/greater is a fairly trivial change, so I'd
rather we did it now and avoid potential fail.

-Sara

--047d7b67083d62840804dc8bb20a--