Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90313
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-SMTP98579FF02E77A48B9ADFAE2F50@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
In-Reply-To: <CAESVnVrjcUxpTMG1HGUMXMTLk6LRevgmyZfX46bgaYXu7xzVUA@mail.gmail.com>
Date: Thu, 7 Jan 2016 21:31:57 +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> <BLU436-SMTP17387745D42702903585025E2F50@phx.gbl> <CAESVnVrjcUxpTMG1HGUMXMTLk6LRevgmyZfX46bgaYXu7xzVUA@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 07.01.2016 um 20:29 schrieb Sara Golemon <pollita@php.net>:
> On Thu, Jan 7, 2016 at 6:04 AM, Bob Weinand <bobwei9@hotmail.com> =
wrote:
>> I think this RFC is attempting to solve the wrong problem... Let me =
explain why:
>>=20
>> a) What do you do in cases like:
>> $a =3D gmp_init(125);
>> $b =3D $a;
>> $b +=3D 10;
>>=20
>> $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.
>>=20
> I do understand that.  My point is that the immutable-value-object
> assumption shouldn't be forced on every class which chooses to
> implement overloading.  It makes sense for GMP, so GMP should
> certainly be allowed to implement it, but GMP's use case isn't
> everyone's use case.
>=20
>> 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.
>>=20
> That's a big IF, but I agree we should have a mind to that leak being
> someday possible and not shoot our future selves in the foot.

Absolutely.

>> b) The main goal is to not needing copies when unnecessary. This =
could then as well apply to simple cases like:
>>=20
>> $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...
>>=20
> I'm confused.  Are you saying that avoiding copies is the main goal of
> the RFC?  Because no, it's not.  Being able to take consistent when
> implementing overloading is the main goal.  An occasional win from not
> having to clone is just a side benefit.
>=20
> Or are you saying that avoiding copies is a benefit of what we have
> now, because it's not.  What we have now is clone-always, regardless
> of self-assignment.

Hmm, re-read the RFC right now. Must have misunderstood something=E2=80=A6=
 you are saying the operations should apply to the objects behind and =
not to the variables?
I think that's a bad idea.

It's fine to optimize clones away, but I think having $a +=3D $b; mean =
anything else (result-wise) than $a =3D $a + $b; is a bad idea (see =
below for why).

>> 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.
>>=20
> I think that approach is piling a whole lot of complexity on for
> minimal theoretical benefit.
>=20
> Again, this RFC is about correctness, not performance.


I'd like to emphasize that by-object is everything, but not "by =
reference like" behavior.
There's a big difference between:

$a =3D gmp_init(125);
$a =3D $b; $b +=3D 2;
// or
$a =3D &$b: $b +=3D 2;

It would be a mistake to make both behaviors equal. After all, I =
consider operator overloading a static operation on two items yielding a =
new result.

Another quirk here is:
$a =3D gmp_init(125);
$b =3D 5;
$c =3D $b;
$b +=3D $a;
// compared to=20
$a =3D 5;
$b =3D gmp_init(125);
$c =3D $b;
$b +=3D $a;

in first example (obviously!) we get $b !=3D $c, but in the second one =
$b =3D=3D $c with this RFC. Especially with GMP, we try to have faked =
by-value (which is very nice for pseudo-scalars).
It'd basically make this impossible now.

So, the big question boils down to: Is $a +=3D $b; something different =
to $a =3D $a + $b; ? (As you say in the RFC.)
My answer is no. Objects are not references. Operators operate on the =
variables, not on the values.

Additional bonus point: This RFC requires that userland operator =
overloading will alter $this based on the operand passed in. But maybe =
we'll decide on another RFC promoting static functions with two operands =
(assuming binary operator) instead.
In the latter case you might return in a div function of a Integer class =
an instance of Fractional instead. Do you then think this should happen:
$a =3D new Integer(3);
$b =3D $a;
$a /=3D 2;
$b instanceof Fractional =3D=3D=3D true??

I don't think so (that would be a very clear violation of by-object =
anyway).

Hence, can we please delay further discussion until we really will have =
decided on the exact semantics of userland operator overloading?

Bob=