Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89985
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVozq-MjaK6R2FRPANanjvSdHb51Gq8B6VfHCUSgUrQk2Q@mail.gmail.com>
References: <CAESVnVozq-MjaK6R2FRPANanjvSdHb51Gq8B6VfHCUSgUrQk2Q@mail.gmail.com>
Date: Mon, 4 Jan 2016 10:39:37 +0100
Message-ID: <CAF+90c8ZWwmB0MwBTN=-tWUf0CnyEw=LjXBBs+PH4h3GNRNSeg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11482e783ef18c05287ee628
Subject: Re: [PHP-DEV] [RFC] Differentiate op from assign-op in operator overloading
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11482e783ef18c05287ee628
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 4, 2016 at 1:37 AM, Sara Golemon <pollita@php.net> wrote:

> This is a separate proposal from the userspace operator overloading I
> put up for Patricio yesterday and aims to fix what I see as a bug in
> our operator overloading implementation (though some may disagree).
>
> It specifically only seeks to differentiate const operations which
> produce a new value from mutations which alter an existing overloaded
> object.
>
> https://wiki.php.net/rfc/assignment-overloading


I'd like to provide some context as to why the current implementation works
as it does. The basic idea is that, prior to the introduction of operator
overloading, primitive operators only worked on types with by-value
semantics (or rather: only returned types with by-value semantics). For
such types it holds, that

    $a op= $b   is equivalent to     $a = $a op $b.

We actually transform the latter operation into the former in pass3
optimization.

Operator overloading was implemented in such a way that this invariant
still holds. To illustrate why keeping this invariant *might* be
beneficial, consider this example from the GMP overloading RFC:

function powm($base, $exponent, $modulus) {
    $result = 1;
    while ($exponent > 0) {
        if ($exponent % 2 == 1) {
            $result = $result * $base % $modulus;
            $exponent--;
        }
        $exponent /= 2;
        $base = ($base * $base) % $modulus;
    }
    return $result;
}

The example appeared in the context that, with operator overloading
supported, the above function could be transparently used either with
ordinary integers or with overloaded GMP objects. However this would not be
true if compound assignment operators would modify the object instead of
creating a new one. In this case the argument passed to $exponent would
always be GMP(0) after the function finishes running. I expect that this
would be somewhat unexpected.

Basically the lack of distinction between assign-op and op-and-assign
enforces that the object behaves as an immutable value object (at least as
far as overloading is concerned).

Nikita

--001a11482e783ef18c05287ee628--