Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92081
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <44350047-C218-4EE9-8282-654D4AF59AF3@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>
	<CAL=_i_myx84YbpnvPA1dA=cRLU-TWUEmkJzV4E7-_1RMNBBh5w@mail.gmail.com>
	<C5B53AF5-2F19-46CC-AD6E-B5CE283D7A3F@gmail.com>
	<44350047-C218-4EE9-8282-654D4AF59AF3@gmail.com>
Date: Sun, 3 Apr 2016 17:34:38 +0100
Message-ID: <CAL=_i_kQb8A+wSK5YYXa0WxKSnjN4rd=E_9mN2P-FBeW0_bnwQ@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=001a114d32f02adc9d052f97307b
Subject: Re: [PHP-DEV] Tests for null coalescing assignment operator
From: pthreads@pthreads.org (Joe Watkins)

--001a114d32f02adc9d052f97307b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Midori,

    I was going to, but then found that comprehensive guide for writing
tests, which has it all covered.

    Current tests covering Zend are in Zend/tests, you can look in there
for inspiration, perhaps looking at the tests for a similar feature.

    As for what to test, I can't say; I haven't seen a working
implementation yet.

Cheers
Joe

On Sun, Apr 3, 2016 at 5:22 PM, Midori Kocak <mtkocak@gmail.com> wrote:

> Joe,
>
> Also that would be more helpful if you wrote some examples or guides, wit=
h
> your advises instead of writing one sentence emails. I would be more happ=
y
> as a rookie that way.
>
> Yours,
> Midori
>
> On 03 Apr 2016, at 18:17, Midori Kocak <mtkocak@gmail.com> wrote:
>
> Hello Joe,
>
> Those were examples for your feedback.
>
> Thanks,
> Midori
>
> On 03 Apr 2016, at 18:16, Joe Watkins <pthreads@pthreads.org> wrote:
>
> 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.co=
m>
>> 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
>> references
>> > 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 giv=
e
>> 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
>> that 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 wit=
h ?:=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 differ=
ences
>> of opinion regarding these two operators.
>> >>>
>> >>> I'll use this chance for some comments on the proposal. I can see th=
e
>> general usefulness of ??=3D, but right now the RFC is severely underspec=
ified
>> 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 wil=
l
>> be the same as $a =3D $a ?? $b, for variable-expression $a and expressio=
n $b.
>> This statement, while a good high-level illustration, does not explain t=
he
>> exact behavior of this operator.
>> >>>
>> >>> For example, consider the expression $a[print 'X'] ??=3D $b. A simpl=
e
>> 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 compoun=
d
>> 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 ass=
ume
>> 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 sequenc=
e
>> >>>
>> >>>     $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 refetc=
h
>> $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 refetch=
ing
>> anymore.
>> >>>
>> >>> So, what would be the desugared call sequence for $a[0][1] ??=3D exp=
r?
>> 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 ther=
e
>> 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
>>
>>
>
>
>

--001a114d32f02adc9d052f97307b--