Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90298
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.176 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c9Od1y9XfJNFvKF4MXJ4jHeTDPb=qzy3eO2-TZ78=u=2g@mail.gmail.com>
References: <CAESVnVozq-MjaK6R2FRPANanjvSdHb51Gq8B6VfHCUSgUrQk2Q@mail.gmail.com>
	<CAF+90c8ZWwmB0MwBTN=-tWUf0CnyEw=LjXBBs+PH4h3GNRNSeg@mail.gmail.com>
	<CAESVnVqKpFnVDAzZEBtUfgQOcnELOOkuqioQUTEm9CKP27U3nw@mail.gmail.com>
	<CAF+90c9Od1y9XfJNFvKF4MXJ4jHeTDPb=qzy3eO2-TZ78=u=2g@mail.gmail.com>
Date: Thu, 7 Jan 2016 11:18:32 -0800
Message-ID: <CAESVnVpuTwQOnv8v29cdSYoFz=caZ2aYE2qnnH1nf-T0K86rvg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
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 5:16 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> GMP objects are, with the exceptions of gmp_setbit and gmp_clrbit, immutable
> value objects. And yes, that's exactly what I would expect any object
> representing a number to be. If $g->add(123) would modify $g instead of
> returning a new object, that would be a major WTF moment for me (and for
> that matter, make the usage very inconvenient.)
>
Sure, but if I called $g->assignAdd(123); then I would expect $g to be modified.
That's the analogue to += so I while I don't disagree with your
conclusion about add(), I do disagree with your analogy.

> I don't get why you denounce immutable value objects as being "non-object
> objects". Seems like very standard usage to me, and one that seems to be
> increasingly preferred.
>
It's not their immutability which makes me call them that.  It's the
lack of anything you would normally see on an object:
* No methods
* No properties
* No constants
* Not initialized via `new`

GMP objects are just resources by another name, and operator
overloading got built around that model, rather than the model enjoyed
by normal objects.  That's why I denounce them as non-object objects.

>> Leaving GMP out of the equation for now (and I think we need to have a
>> longer discussion about this, but in another thread), I think the
>> question which remains is: Do we want more non-object objects?
>> Should, for example, SimpleXMLbe constrained by GMP's goals when
>> implementing overloaded operators (no, I don't know what this would
>> look like, it's just a for-instance).
>
>
> If we leave GMP out of the equation, then yes, I agree. Whether $a op= $b
> should create a new object or modify an existing one depends on the nature
> of that object. For GMP (and Rational and Complex and Currency and most
> other things that tend to be immutable value objects) I think the behavior
> we currently provide is preferable (though I guess that is subject to
> discussion), but for some other applications of operator overloading, this
> choice wouldn't really make sense.
>
Agreed.  The choice of mutability needs to be class specific, which is
why I propose letting the class enforce it rather than dictating it
from the engine and not giving the classes a choice.

> It's currently already possible to distinguish this based on whether result
> == op1. However we reserve the right (i.e. have some currently non-default
> optimizations doing that) to have result == op1 in $a = $a + $b operations
> as well, so this check is not robust. So, it would be good to change things
> to pass in separate ZEND_ASSIGN_* flags. Will make the implementation even
> more ugly though :)
>
Right, that optimization pass is slightly more complex.  I haven't had
the bandwidth to dig into it, but assuming a clean/efficient solution
is available, would you be okay with the rest of the proposal overall?
(Non-binding)

-Sara