Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90121
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.194 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c8ZWwmB0MwBTN=-tWUf0CnyEw=LjXBBs+PH4h3GNRNSeg@mail.gmail.com>
References: <CAESVnVozq-MjaK6R2FRPANanjvSdHb51Gq8B6VfHCUSgUrQk2Q@mail.gmail.com>
	<CAF+90c8ZWwmB0MwBTN=-tWUf0CnyEw=LjXBBs+PH4h3GNRNSeg@mail.gmail.com>
Date: Tue, 5 Jan 2016 10:17:17 -0800
Message-ID: <CAESVnVqKpFnVDAzZEBtUfgQOcnELOOkuqioQUTEm9CKP27U3nw@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 Mon, Jan 4, 2016 at 1:39 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> I'd like to provide some context as to why the current implementation works
> as it does.
>
Thanks for the context, Niki.  It makes sense that, with GMP as the
flagship target of operator overloading, stripping away the by-ref
semantics of objects would be appealing.  This way GMP objects just
look like regular numbers.

Except they're not.  Nor are they really objects at this point.  They
have no methods, no properties, they're not instantiated with the new
keyword, and they have by-value semantics (mostly).

That feels really odd to me, that GMP objects, at the moment of their
inception were /designed/ to be non-object objects.  Would this carry
forward to any OOP API we might introduce in the future?  i.e.
$g->add(123);  wouldn't muttate $g, but would return a new instance?

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 the answer to that is "No" (which I think it is), then the question
is: Can we modify the do_operation API in a way that allows GMP to
remain psuedo-by-value while still allowing other internal objects
which implement overloading to be more correct?   I think we can.
I'll cobble together a gist of how that might look if there's
tentative buy-in, but I'm pretty sure PHP7's variable model does let
us do that.

-Sara