Combine ??= and ?:= assignment operator rfc's.

php.internals

Midori Kocak

10 years ago
Hi Everyone, I think it's better idea to combine those two assignment operator RFC’s. So I am going to close the current one and open ??= with ?:= What do you think? And we have to find better names. Wishes, Midori Kocak

Dan Ackroyd

10 years ago
On 25 March 2016 at 10:59, Midori Kocak <mtkocak@gmail.com> wrote:
> I think it's better idea to combine those two assignment operator RFC’s. So I am going to close the current one and open ??= with ?:=
Keeping RFCs separate is good in my opinion. In general it allows the discussions to be clear, and that is particularly true here, as there are issues with ternaries in PHP that do not affect null coalesce operators. But in this case, the vote for ??= is underway. The only reason to alter the timeline of the vote should be if a severe problem was found with the RFC. So please leave it to run. btw I actually think we ought to have someone other than the RFC author open and close the voting as there have been some votes opened/closed that have been surprises. cheers Dan

Nikita Popov

10 years ago
On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtkocak@gmail.com> wrote:
> Hi Everyone, > > I think it's better idea to combine those two assignment operator RFC’s. > So I am going to close the current one and open ??= with ?:= > 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 ??= operator vote is currently unanimous at 24:0, while the ?:= 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 ??=, 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 ??= $b will be the same as $a = $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'] ??= $b. A simple desugaring into $a[print 'X'] = $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 ??= would behave the same way. However, with ??= the problem becomes more complicated. Let us assume that $a is an ArrayAccess object and consider the expression $a[0] ??= $b. Let us further assume that $x = $a->offsetGet(0) is non-null. Will $a[0] ??= $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] = $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] = $b? Let us now assume that $a is a recursive ArrayAccess object with by-reference offsetGet() and consider the expression $a[0][1] ??= expr. For a normal compound assignment operator, this would issue the call sequence $b = expr; $x =& $a->offsetGet(0); $y = $x->offsetGet(1); $y OP= $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 ??= 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 ??= 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] ??= expr? Something like this? if (!$a->offsetHas(0)) { goto assign; } $x = $a->offsetGet(0); if (x === null) { goto assign; } if (!$x->offsetHas(0)) { goto assign; } $y = $x->offsetGet(0); if ($y === null) { goto assign; } goto done; assign: $b = expr; $x =& $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 ??= (and ?:=) 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

Midori Kocak

10 years ago
http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html <http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html>

Björn Larsson

10 years ago
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örn Larsson Den 2016-03-25 kl. 13:46, skrev Midori Kocak:

Joe Watkins

10 years ago
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örn Larsson <bjorn.x.larsson@telia.com> wrote:

Midori Kocak

10 years ago
Dear All, Based on the concerns I wrote some tests. Can you check those and give feedback? Also, in ruby, $a ||= $b, the implementation is not equal to $a = $a || $b, but is equal to $a || $a = $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

Björn Larsson

10 years ago
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örn Larsson PS Maybe best to finish implementation and tests first. Den 2016-04-03 kl. 03:17, skrev Midori Kocak:

Midori Kocak

10 years ago
Yes, I think I should too. But still no feedbacks :(

Joe Watkins

10 years ago
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:

Midori Kocak

10 years ago
Hello Joe, Those were examples for your feedback. Thanks, Midori

Midori Kocak

10 years ago
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

Joe Watkins

10 years ago
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: