Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89977
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com>
References: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com>
Date: Sun, 3 Jan 2016 11:11:57 +0100
Message-ID: <CAF+90c-Bd+mCWz7wq+P9KA_a_r_fj9zHZh_j7of8OEUZ=beZHQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>, patriciotarantino@gmail.com
Content-Type: multipart/alternative; boundary=001a11414910129f9005286b3c86
Subject: Re: [PHP-DEV] RFC Operator Overloading in Userspace
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11414910129f9005286b3c86
Content-Type: text/plain; charset=UTF-8

On Sun, Jan 3, 2016 at 3:14 AM, Sara Golemon <pollita@php.net> wrote:

> Patricio Tarantino has asked me to help him propose Operator
> Overloading in PHP 7.1 (based in part on my operator extension in
> PECL).  I think we can expose this to usespace as magic methods with
> very little overhead (the runtime check and dispatch is already there,
> after all).
>
> I do think that the "Future Expansion" section bears following through
> with as well, but the basic set of methods already hooked for GMP
> would be a nice start.
>
> https://wiki.php.net/rfc/operator-overloading
>
> -Sara
>

Thanks for the proposal, Sara! A few questions to clarify:

1. If an object implements __add__, will $a += $b be equivalent to $a =
$a->__add($b) and ++$a be equivalent to $a = $a->__add(1)? This is how
internal operator overloading currently works (we have no separate
overloads for assign ops). Will this RFC also work this way?

2. Regarding associativity, the RFC states "When both operands to a binary
expression implement operator overloading, the left-hand operand's handler
will be invoked. If only one of the two implement overloading, then that
side is invoked with the relative operation inverted as necessary." This
sounds rather 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 be static methods with two operands.

3. Relatedly, consider the situation where $obj1 op $obj2, where $obj1 and
$obj2 are instances of different classes, both of which have distinct
overloads of the op operator. It so happens that the op-implementation of
$obj1 does not support operations against $obj2, while the
op-implementation on $obj2 does support operations against $obj1. The
op-implementation of $obj1 will be invoked first -- will there be some way
for it to signal "I don't support this operation", thus allowing the
op-implementation of $obj2 to be used?

Thanks,
Nikita

--001a11414910129f9005286b3c86--