Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90250
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.90 as permitted sender)
Message-ID: <BLU436-SMTP17387745D42702903585025E2F50@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
In-Reply-To: <CAESVnVozq-MjaK6R2FRPANanjvSdHb51Gq8B6VfHCUSgUrQk2Q@mail.gmail.com>
Date: Thu, 7 Jan 2016 15:04:04 +0100
CC: PHP internals <internals@lists.php.net>,
 Nikita Popov <nikita.ppv@gmail.com>
Content-Transfer-Encoding: quoted-printable
References: <CAESVnVozq-MjaK6R2FRPANanjvSdHb51Gq8B6VfHCUSgUrQk2Q@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] [RFC] Differentiate op from assign-op in operator overloading
From: bobwei9@hotmail.com (Bob Weinand)

> Am 04.01.2016 um 01:37 schrieb Sara Golemon <pollita@php.net>:
>=20
> 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).
>=20
> It specifically only seeks to differentiate const operations which
> produce a new value from mutations which alter an existing overloaded
> object.
>=20
> https://wiki.php.net/rfc/assignment-overloading

Hey,

I think this RFC is attempting to solve the wrong problem... Let me =
explain why:

a) What do you do in cases like:
$a =3D gmp_init(125);
$b =3D $a;
$b +=3D 10;

$a and $b hold the same object reference, so we'd need to do an implicit =
clone (separation) before passing it to the assign ops, or we are going =
to break the immutable-value-object assumption.
That risks to be be problematic. As long as it is internal, we could =
deal with it internally. When we leak operator overloading to userland, =
not so much.

b) The main goal is to not needing copies when unnecessary. This could =
then as well apply to simple cases like:
$a =3D gmp_init(125);
$b =3D $a + 10;
/* $a isn't used anymore later */
or just explicit:
$a =3D $a + 10; # instead of $a +=3D 10; // under some circumstances =
that may be more readable...

With opcache analysis we'll probably be able to determine when we won't =
use the symtable directly (via varvars, get_defined_variables() etc.), =
where this will present another valuable optimization possibly.

At that point you would possibly rather explicitly check: "are we at the =
end of a variable range (if CV) and the refcount of the object =3D=3D =
1?" and eventually forward that information to userland as optional =
third param.
Which would give you the most optimization possible; and even applicable =
in the example Nikita provided with sets.

Example:
function or($a, $b, $mutable =3D OVERLOAD::NO_REUSE) {
    switch ($mutable) {
        case OVERLOAD::REUSE_OP1_OP2:
        case OVERLOAD::REUSE_OP1:
            $a->add($b);
            return $a;
        case OVERLOAD::REUSE_OP2:
            $b->add($a);
            return $b;
        default:
            $a =3D clone $a;
            $a->add($b);
            return $a;
    }
}

Bob=