Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92080 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12918 invoked from network); 3 Apr 2016 16:22:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Apr 2016 16:22:56 -0000 Authentication-Results: pb1.pair.com smtp.mail=mtkocak@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=mtkocak@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: mtkocak@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-lf0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:35291] helo=mail-lf0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 82/2A-29546-F5341075 for ; Sun, 03 Apr 2016 12:22:55 -0400 Received: by mail-lf0-f42.google.com with SMTP id c126so17819465lfb.2 for ; Sun, 03 Apr 2016 09:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ZwTFJESDQkJlukTH2akYcA3WdxHOxfOrh5BFPaqFCWw=; b=JU02tJb5Qil11psDnBeMDwszlvJmxfpXN1rRwr7NiN0lLdtil2tjLuoRSvNe3dnDHf pzgRQSqEbtwDLxRFnp7fZOg1s18OYfnVPdMr8dfZrwmOZF08NXfXY61CDaTo7rmdxTDv aHb64itvzU14/x/GVxXo9IABXTb2wXqN8G1eQedfKB3/u86SxxrINpbbzSrc58blJSWg ivuHZH0RL3trYZXg9jvt/QbluVgMenT2SfSsR4WvUC7yP61gz6M0hxvuk/wwtRq2fMKZ a3oChkTb0Lm30mN1OHkULLLwZikMySUWj46uox5XavxxirHciqgqly50UZ/gDF7JRc1G sg1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZwTFJESDQkJlukTH2akYcA3WdxHOxfOrh5BFPaqFCWw=; b=fh13UEWjUkEgnrgs1rWVjWQILFvyL56Lir9VV1rSGl57HnqSZxsnVVndzsqAYFWvza gpE0LDeU83k0S2+5jg12GM2IGdyfYWbzQhd3eb4qfsgwCjyiWNPAkl0SzVjD7UsRjyzh jX8uKjJDGa92K1L0z6ExN1Q41l+E7ekKSG5PogpN54d8RTka5z2x7KTf/yVhxtO2Hriq JkEuWwtCQNzVSV79GdviSWMMLQi3zVfGZyJeXP4uv3OlR4QgfhSA9wKO5lSCHIWHUoY8 BEhN9/91bP9WzD0HiiiGLoBjpklPRTQ5jXiZgq0ZpN8XoSUMjN+KIvvTXeOM1fgyRihv m3Cg== X-Gm-Message-State: AD7BkJIqlaxI3tJjuwq64DOB5gISKyJMw8LQtmDwsY5vH5pQtPj6zPEWopkN0fF8c+5uKw== X-Received: by 10.194.57.100 with SMTP id h4mr14472605wjq.18.1459700572242; Sun, 03 Apr 2016 09:22:52 -0700 (PDT) Received: from [10.0.0.3] (26.85.broadband11.iol.cz. [90.178.85.26]) by smtp.gmail.com with ESMTPSA id t7sm24532573wjf.39.2016.04.03.09.22.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Apr 2016 09:22:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C825D431-E366-4BEA-A8C0-390DAB7008EE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: Date: Sun, 3 Apr 2016 18:22:50 +0200 Cc: =?utf-8?Q?Bj=C3=B6rn_Larsson?= , Nikita Popov , PHP internals Message-ID: <44350047-C218-4EE9-8282-654D4AF59AF3@gmail.com> References: <9399032E-5BAA-4ABF-81AD-13716790D8DB@gmail.com> <63C58928-255D-41A1-9D6E-4773CF9DB356@gmail.com> <5700FB39.2030303@telia.com> To: Joe Watkins X-Mailer: Apple Mail (2.3124) Subject: Re: [PHP-DEV] Tests for null coalescing assignment operator From: mtkocak@gmail.com (Midori Kocak) --Apple-Mail=_C825D431-E366-4BEA-A8C0-390DAB7008EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joe, Also that would be more helpful if you wrote some examples or guides, = with your advises instead of writing one sentence emails. I would be = more happy as a rookie that way. Yours, Midori > On 03 Apr 2016, at 18:17, Midori Kocak wrote: >=20 > Hello Joe, >=20 > Those were examples for your feedback. >=20 > Thanks, > Midori >=20 >> On 03 Apr 2016, at 18:16, Joe Watkins > wrote: >>=20 >> Morning Midori, >>=20 >> PHP doesn't use PHPUnit tests. >>=20 >> Please see: https://qa.php.net/write-test.php = >>=20 >> Cheers >> Joe >>=20 >> On Sun, Apr 3, 2016 at 3:41 PM, Midori Kocak > wrote: >> Yes, I think I should too. But still no feedbacks :( >>=20 >> > On 03 Apr 2016, at 13:15, Bj=C3=B6rn Larsson = > 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 = 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 = = > >> >> >> >> 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 > wrote: >> >>> >> >>> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak >> 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 = underspecified 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 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 = 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 = 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 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 refetching 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 >> >> >> > >>=20 >>=20 >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php = >>=20 >>=20 >=20 --Apple-Mail=_C825D431-E366-4BEA-A8C0-390DAB7008EE--