Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <ABD5C8BE-55E9-4F3A-8957-C076AFE8C3D0@gmail.com>
References: <9399032E-5BAA-4ABF-81AD-13716790D8DB@gmail.com>
	<CAF+90c8yhAfzTP7apPSbbrcSuqhiBv2Y_XAD=U5MLG+SoezFRA@mail.gmail.com>
	<63C58928-255D-41A1-9D6E-4773CF9DB356@gmail.com>
	<5700FB39.2030303@telia.com>
	<ABD5C8BE-55E9-4F3A-8957-C076AFE8C3D0@gmail.com>
Date: Sun, 3 Apr 2016 17:16:14 +0100
Message-ID: <CAL=_i_myx84YbpnvPA1dA=cRLU-TWUEmkJzV4E7-_1RMNBBh5w@mail.gmail.com>
To: Midori Kocak <mtkocak@gmail.com>
Cc: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>, 
	Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114229525dcadf052f96ee49
Subject: Re: [PHP-DEV] Tests for null coalescing assignment operator
From: pthreads@pthreads.org (Joe Watkins)

--001a114229525dcadf052f96ee49
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Morning Midori,

    PHP doesn't use PHPUnit tests.

    Please see: https://qa.php.net/write-test.php

Cheers
Joe

On Sun, Apr 3, 2016 at 3:41 PM, Midori Kocak <mtkocak@gmail.com> wrote:

> Yes, I think I should too. But still no feedbacks :(
>
> > On 03 Apr 2016, at 13:15, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.com=
>
> wrote:
> >
> > Hi Midori,
> >
> > Will you update the RFC also? Even if it's not the normal way of doing
> > things, one should keep in mind that RFC's are often listed as referenc=
es
> > in books about PHP, being the first piece of documentation. Two such
> > examples are:
> > - https://daveyshafik.com/archives/book/upgrading-to-php-7
> >  # In Appendix B
> > - http://www.php7book.com
> >  # At the end of every chapter
> >
> > Regards //Bj=C3=B6rn Larsson
> >
> > PS Maybe best to finish implementation and tests first.
> >
> > Den 2016-04-03 kl. 03:17, skrev Midori Kocak:
> >> Dear All,
> >>
> >> Based on the concerns I wrote some tests. Can you check those and give
> feedback? Also, in ruby, $a ||=3D $b, the implementation is not equal to =
$a =3D
> $a || $b, but is equal to $a || $a =3D $b; I am a little bit confused, I =
am
> not entirely sure, but I guess this approach would solve our problems.
> >>
> >> https://gist.github.com/midorikocak/abc9fd9b6ca30359d201bc859edba9ee <
> https://gist.github.com/midorikocak/abc9fd9b6ca30359d201bc859edba9ee>
> >>
> >> We can use these examples as the part of the new documentation and as =
a
> guideline for implementation tests. Can you add also any extreme cases th=
at
> should raise errors to my test?
> >>
> >> Yours,
> >> Midori
> >>
> >>> 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 t=
he
> ?:=3D vote was closed at something like 9:2, so there clearly are differe=
nces
> 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 underspeci=
fied
> 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 underspecified?
> >>>
> >>> The only statement the RFC essentially makes is that $a ??=3D $b will=
 be
> 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 th=
e
> 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 compound
> 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 assu=
me
> 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 assignment =
is
> not really necessary, as we're just reassigning the same value. So, does
> 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 expr.=
 For
> a normal compound assignment operator, this would issue the call sequence
> >>>
> >>>     $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 refetchi=
ng
> 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
>
>

--001a114229525dcadf052f96ee49--