Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90302
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.217.174 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <BLU436-SMTP17387745D42702903585025E2F50@phx.gbl>
References: <CAESVnVozq-MjaK6R2FRPANanjvSdHb51Gq8B6VfHCUSgUrQk2Q@mail.gmail.com>
	<BLU436-SMTP17387745D42702903585025E2F50@phx.gbl>
Date: Thu, 7 Jan 2016 11:29:55 -0800
Message-ID: <CAESVnVrjcUxpTMG1HGUMXMTLk6LRevgmyZfX46bgaYXu7xzVUA@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: PHP internals <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Differentiate op from assign-op in operator overloading
From: pollita@php.net (Sara Golemon)

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:
>
> a) What do you do in cases like:
> $a = gmp_init(125);
> $b = $a;
> $b += 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.
>
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.

> 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.
>
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.

> b) The main goal is to not needing copies when unnecessary. This could then as well apply to simple cases like:
>
> $a = gmp_init(125);
> $b = $a + 10;
> /* $a isn't used anymore later */
> or just explicit:
> $a = $a + 10; # instead of $a += 10; // under some circumstances that may be more readable...
>
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.

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.

> 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 == 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.
>
I think that approach is piling a whole lot of complexity on for
minimal theoretical benefit.

Again, this RFC is about correctness, not performance.

-Sara