Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92071
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.173 cause and error)
MIME-Version: 1.0
In-Reply-To: <570011F9.2080903@telia.com>
References: <9399032E-5BAA-4ABF-81AD-13716790D8DB@gmail.com>
	<CAF+90c8yhAfzTP7apPSbbrcSuqhiBv2Y_XAD=U5MLG+SoezFRA@mail.gmail.com>
	<7C805132-E4B3-482A-8B4D-8E949C06639F@gmail.com>
	<570011F9.2080903@telia.com>
Date: Sat, 2 Apr 2016 20:07:04 +0100
Message-ID: <CAL=_i_kz=FC2zSgdYig0zuvPFsupirYJtB30coUACL4pBoL3sQ@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Midori Kocak <mtkocak@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1146f62a7771b7052f85336c
Subject: Re: [PHP-DEV] Combine ??= and ?:= assignment operator rfc's.
From: pthreads@pthreads.org (Joe Watkins)

--001a1146f62a7771b7052f85336c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Evening internals,

    It doesn't matter that NCE passed, the job is not finished.

    The RFC will stand forever as the first piece of documentation
available for this feature, and it's terrible.

    The patch is also broken, I'm aware that Sara has been working on an
alternative implementation, imo the vote should have been halted while the
implementation was finalized.

    Minimally the RFC needs work still, the patch needs to be updated on
the RFC to point to Sara's one (if it's finished, I don't even know if it's
finished), and the current PR closed.

Cheers
Joe

On Sat, Apr 2, 2016 at 7:39 PM, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.c=
om>
wrote:

> Well, now the RFC has passed so congratulation on that one!
>
> I can agree a bit that the RFC itself is a bit under specified,
> but what to do about it? Some options:
> - Expand it in the PHP documentation, but then the documentation
>   becomes the master not the RFC itself.
> - Update the RFC itself with some more examples, maybe not
>   feasible given that the voting is over.
> - Update RFC with link to Ruby.
>
> What do you think? Anyway, I'm not so privy to the RFC process
> so maybe this is a non issue...
>
> Regards //Bj=C3=B6rn Larsson
>
>
> Den 2016-03-25 kl. 13:46, skrev Midori Kocak:
>
>>
>> http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5=
488.html
>> <
>> http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5=
488.html
>> >
>>
>> On 25 Mar 2016, at 13:42, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>>
>>> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtkocak@gmail.com
>>> <mailto:mtkocak@gmail.com>> wrote:
>>> Hi Everyone,
>>>
>>> I think it's better idea to combine those two assignment operator RFC=
=E2=80=99s.
>>> So I am going to close the current one and open ??=3D with ?:=3D
>>> What do you think? And we have to find better names.
>>>
>>> Wishes,
>>> Midori Kocak
>>>
>>> I'd prefer to keep them separate, or at least keep their votes separate=
.
>>> The ??=3D operator vote is currently unanimous at 24:0, while the ?:=3D=
 vote
>>> was closed at something like 9:2, so there clearly are differences of
>>> opinion regarding these two operators.
>>>
>>> I'll use this chance for some comments on the proposal. I can see the
>>> general usefulness of ??=3D, but right now the RFC is severely underspe=
cified
>>> and I'm uncomfortable voting on it in it's current form as so much will
>>> depend on the final implementation. So, what do I mean by underspecifie=
d?
>>>
>>> The only statement the RFC essentially makes is that $a ??=3D $b will b=
e
>>> the same as $a =3D $a ?? $b, for variable-expression $a and expression =
$b.
>>> This statement, while a good high-level illustration, does not explain =
the
>>> exact behavior of this operator.
>>>
>>> For example, consider the expression $a[print 'X'] ??=3D $b. A simple
>>> desugaring into $a[print 'X'] =3D $a[print 'X'] ?? $b will result in 'X=
'
>>> being printed twice. However, this is not how all other existing compou=
nd
>>> assignment operators behave: They will print X only once, as the LHS is
>>> only evaluated once. I assume that ??=3D would behave the same way.
>>>
>>> However, with ??=3D the problem becomes more complicated. Let us assume
>>> that $a is an ArrayAccess object and consider the expression $a[0] ??=
=3D $b.
>>> Let us further assume that $x =3D $a->offsetGet(0) is non-null. Will $a=
[0]
>>> ??=3D $b result in a call to $a->offsetSet(0, $x)? This is what would
>>> normally happen with a compound assignment operator and what would be
>>> implied by the desugaring $a[0] =3D $a[0] ?? $b. However this assignmen=
t is
>>> not really necessary, as we're just reassigning the same value. So, doe=
s
>>> the call happen or not? Is the proper desugaring maybe if (!isset($a[0]=
))
>>> $a[0] =3D $b?
>>>
>>> Let us now assume that $a is a recursive ArrayAccess object with
>>> by-reference offsetGet() and consider the expression $a[0][1] ??=3D exp=
r. For
>>> a normal compound assignment operator, this would issue the call sequen=
ce
>>>
>>>      $b =3D expr;
>>>      $x =3D& $a->offsetGet(0);
>>>      $y =3D $x->offsetGet(1);
>>>      $y OP=3D $b;
>>>      $x->offsetSet(1, $y);
>>>
>>> Note that we only issue one offsetSet() at the end. We do not refetch $=
x
>>> via $a->offsetGet(0). How would the same work with the ??=3D operator? =
As the
>>> RHS is evaluated lazily, it is my opinion that only performing the
>>> offsetSet() call without refetching $x beforehand would violate PHP's
>>> indirection memory model. Additionally as ??=3D has to fetch offsets in
>>> BP_VAR_IS mode, we likely wouldn't be able to write them without refetc=
hing
>>> anymore.
>>>
>>> So, what would be the desugared call sequence for $a[0][1] ??=3D expr?
>>> Something like this?
>>>
>>>      if (!$a->offsetHas(0)) {
>>>          goto assign;
>>>      }
>>>      $x =3D $a->offsetGet(0);
>>>      if (x =3D=3D=3D null) {
>>>          goto assign;
>>>      }
>>>      if (!$x->offsetHas(0)) {
>>>          goto assign;
>>>      }
>>>      $y =3D $x->offsetGet(0);
>>>      if ($y =3D=3D=3D null) {
>>>          goto assign;
>>>      }
>>>      goto done;
>>> assign:
>>>      $b =3D expr;
>>>      $x =3D& $a->offsetGet(0);
>>>      $x->offsetSet(1, $b);
>>> done:
>>>
>>> That would be some first thoughts on the issue, though I'm sure there
>>> are more subtleties involved. I'd like to see the exact behavior of ??=
=3D
>>> (and ?:=3D) specified.
>>>
>>> I'm also pretty sure that writing a patch for this will not be entirely
>>> easy. The combination of execute-once LHS side-effects and lazy RHS
>>> execution does not translate well to PHP's VM constraints.
>>>
>>> Regards,
>>> Nikita
>>>
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1146f62a7771b7052f85336c--