Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89980
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.220.49 as permitted sender)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAF+90c-Bd+mCWz7wq+P9KA_a_r_fj9zHZh_j7of8OEUZ=beZHQ@mail.gmail.com>
Date: Sun, 3 Jan 2016 11:39:02 -0800
Cc: Sara Golemon <pollita@php.net>,
 PHP internals <internals@lists.php.net>, patriciotarantino@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-ID: <501AD5B6-1CF2-4F3B-B394-F7AC8A8C1C75@golemon.com>
References: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com> <CAF+90c-Bd+mCWz7wq+P9KA_a_r_fj9zHZh_j7of8OEUZ=beZHQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] RFC Operator Overloading in Userspace
From: php@golemon.com (Sara Golemon)


> On Jan 3, 2016, at 02:11, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Thanks for the proposal, Sara! A few questions to clarify:
>=20
One point of order.  It's Patricio's peoposal, I'm just helping him move it a=
long.

> 1. If an object implements __add__, will $a +=3D $b be equivalent to $a =3D=
 $a->__add($b) and ++$a be equivalent to $a =3D $a->__add(1)? This is how in=
ternal operator overloading currently works (we have no separate overloads f=
or assign ops). Will this RFC also work this way?
To be quite honest, I'd rather it DIDN'T work that way.  As I said to Stas, I=
 regard our current crossloading as broken since it forces new object creati=
on when the statement visually calls for mutation.

Semantically, what we do for GMP right now isn't sound, even if the distinct=
ion doesn't seem to be breaking anyone.

>=20
> 2. Regarding associativity, the RFC states "When both operands to a binary=
 expression implement operator overloading, the left-hand operand's handler w=
ill be invoked. If only one of the two implement overloading, then that side=
 is invoked with the relative operation inverted as necessary." This sounds r=
ather fishy to me, as not all operations are abelian. In particular __sub, _=
_div, __pow and __concat are *usually* non-commutative. As such, the current=
 RFC does not appear to leave room for supporting things like 1/$complex or 1=
-$complex or e**$complex. As such I wonder if these magic methods oughtn't b=
e static methods with two operands.
>=20
I did consider that as an alternate option.

function overload_register($op, $lhtype, $rhtype, $callback);

overload_type(ZEND_ADD, 'Complex', 'any', 'Complex::add');

This would get pretty expensive in terms of large lookup tables though, so I=
'm hesitant there.

> 3. Relatedly, consider the situation where $obj1 op $obj2, where $obj1 and=
 $obj2 are instances of different classes, both of which have distinct overl=
oads of the op operator. It so happens that the op-implementation of $obj1 d=
oes not support operations against $obj2, while the op-implementation on $ob=
j2 does support operations against $obj1. The op-implementation of $obj1 wil=
l be invoked first -- will there be some way for it to signal "I don't suppo=
rt this operation", thus allowing the op-implementation of $obj2 to be used?=

>=20
I do like the idea of being able to signal type failures.   Would a specific=
 exception be too heavyweight?  Or just return "ConversionFailure" object in=
stance or something...

-Sara=