Re: [PHP-DEV] Looking (not very far) ahead to PHP 7.1

[Midori Kocak]

Hello Everyone,

Remember the ??=. I had a faulty implementation and after that a serious 
surgery and I did not have the time to update my implementation. I am OK now 
but what should I do with my RFC? Can somebody implement it or should I move 
forward with the implementation. What do you guys say? What is your advice?

Best wishes.

Midori Kocak
Computer Scientist & Engineer
http://www.mynameismidori.com <http://www.mynameismidori.com/>

“The most beautiful thing we can experience is the mysterious. It is the source 
of all true art and science.” Albert Einstein

> On 06 May 2016, at 09:25, Joe Watkins <pthre...@pthreads.org 
> <mailto:pthre...@pthreads.org>> wrote:
> 
> -- Forwarded message --
> From: Joe Watkins <pthre...@pthreads.org <mailto:pthre...@pthreads.org>>
> Date: Fri, May 6, 2016 at 8:23 AM
> Subject: Re: [PHP-DEV] Looking (not very far) ahead to PHP 7.1
> To: Björn Larsson <bjorn.x.lars...@telia.com 
> <mailto:bjorn.x.lars...@telia.com>>
> Cc: Davey Shafik <da...@php.net <mailto:da...@php.net>>
> 
> 
> Morning,
> 
>   PHP 5 has been with us for a long time, towards the end of it's life, it
> didn't make much sense to have protracted pre-release periods.
> 
>   PHP 7 has been with us for no time at all, about 5 minutes; It still
> creates a fair amount of core (/Zend) bugs, and there are only a few people
> who are able, or who bother, to search for and or resolve such bugs.
> 
>   An RFC does not *need* to be accompanied by an implementation (for some
> reason), so we can't very well say "no more RFC after X". All we are
> concerned about is the implementation that accompanies the RFC.
> 
>   Everyone should move forward with their RFC, and voting, in the
> knowledge that if the implementation is not ready for Beta 1, it's too
> late.
> 
>   Worth noting that we're only really talking about the feature kind of
> RFC: If some internal problem is found that requires an RFC discussion to
> resolve and choose a solution for, no problem - that's what we should be
> doing at this point.
> 
>   We don't really need to be any more restrictive than that.
> 
>   I quite often supply patches for RFC discussions, I get that it's
> annoying for someone to say "staph". I get that 7 is shiny, it's easy to
> implement complex features, I get that we all waited a long time for such a
> platform.
> 
>   I also get that 7.2 is going to be a thing :)
> 
> Cheers
> Joe
> 
> 
> 
> On Thu, May 5, 2016 at 9:58 PM, Björn Larsson <bjorn.x.lars...@telia.com 
> <mailto:bjorn.x.lars...@telia.com>>
> wrote:
> 
>> Ok, well I guess there is always room to change at alpha1 when
>> all RFC's should be on the table. Agree that 7.1 looks like a busy
>> release :-)
>> 
>> I mean, earlier (5.6 & maybe also 7.0) no new RFC's introduced
>> after alpha1 and voting closed by first beta. Same strategy in 7.1?
>> Cheers //Björn
>> 
>> 
>> Den 2016-05-05 kl. 22:53, skrev Davey Shafik:
>> 
>> Bjorn,
>> 
>> I had the same suggestion, but Joe has convinced me that due to the amount
>> and extent of changes we'd rather have more than we need, than too few!
>> 
>> - Davey
>> 
>> On Thu, May 5, 2016 at 1:48 PM, Björn Larsson <bjorn.x.lars...@telia.com 
>> <mailto:bjorn.x.lars...@telia.com>>
>> wrote:
>> 
>>> Aha, I see & tnx. It's not on the front-page so I missed it.
>>> 
>>> One reflection is that you have similar amount of
>>> alpha / beta / RC steps like for 7.0 that was a major
>>> release. Looking at todo lists on 5.x. the numbers of
>>> steps are smaller. On the other hand 7.1 seems like
>>> a busy release with typed properties etc
>>> 
>>> Just my 5c...
>>> 
>>> Cheers //Björn
>>> Den 2016-05-05 kl. 22:36, skrev Davey Shafik:
>>> 
>>> The same one used for the vote is where we are currently working. Nothing
>>> is set in stone yet!
>>> 
>>> https://wiki.php.net/todo/php71 <https://wiki.php.net/todo/php71>
>>> 
>>> On Thu, May 5, 2016 at 1:35 PM, Björn Larsson <
>>> <bjorn.x.lars...@telia.com>bjorn.x.lars...@telia.com> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Short question, will you make a todolist like for 7.0 on:
>>>> - https://wiki.php.net/todo
>>>> 
>>>> And good luck with the work as RMs! Already looking
>>>> forward to 7.1 with some exciting content.
>>>> 
>>>> Regards //Björn Larsson
>>>> 
>>&g

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

[Midori Kocak]

+1 

> On 07 Apr 2016, at 14:21, Andrea Faulds  wrote:
> 
> Hi everyone,
> 
> Bob and I have made an RFC which proposes an alternative syntax for list():
> 
> https://wiki.php.net/rfc/short_list_syntax
> 
> Please tell us your thoughts.
> 
> Thanks!
> -- 
> Andrea Faulds
> https://ajf.me/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Tests for null coalescing assignment operator

[Midori Kocak]

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 <mtko...@gmail.com> wrote:
> 
> Hello Joe,
> 
> Those were examples for your feedback.
> 
> Thanks,
> Midori
> 
>> On 03 Apr 2016, at 18:16, Joe Watkins <pthre...@pthreads.org 
>> <mailto:pthre...@pthreads.org>> wrote:
>> 
>> Morning Midori,
>> 
>> PHP doesn't use PHPUnit tests.
>> 
>> Please see: https://qa.php.net/write-test.php 
>> <https://qa.php.net/write-test.php>
>> 
>> Cheers
>> Joe
>> 
>> On Sun, Apr 3, 2016 at 3:41 PM, Midori Kocak <mtko...@gmail.com 
>> <mailto:mtko...@gmail.com>> wrote:
>> Yes, I think I should too. But still no feedbacks :(
>> 
>> > On 03 Apr 2016, at 13:15, Björn Larsson <bjorn.x.lars...@telia.com 
>> > <mailto:bjorn.x.lars...@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 references
>> > in books about PHP, being the first piece of documentation. Two such
>> > examples are:
>> > - https://daveyshafik.com/archives/book/upgrading-to-php-7 
>> > <https://daveyshafik.com/archives/book/upgrading-to-php-7>
>> >  # In Appendix B
>> > - http://www.php7book.com <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:
>> >> 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> 
>> >> <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@gmail.com 
>> >>> <mailto:nikita@gmail.com>> wrote:
>> >>>
>> >>> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtko...@gmail.com 
>> >>> <mailto:mtko...@gmail.com> <mailto:mtko...@gmail.com 
>> >>> <mailto:mtko...@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

Re: [PHP-DEV] Tests for null coalescing assignment operator

[Midori Kocak]

Hello Joe,

Those were examples for your feedback.

Thanks,
Midori

> On 03 Apr 2016, at 18:16, Joe Watkins <pthre...@pthreads.org> wrote:
> 
> Morning Midori,
> 
> PHP doesn't use PHPUnit tests.
> 
> Please see: https://qa.php.net/write-test.php 
> <https://qa.php.net/write-test.php>
> 
> Cheers
> Joe
> 
> On Sun, Apr 3, 2016 at 3:41 PM, Midori Kocak <mtko...@gmail.com 
> <mailto:mtko...@gmail.com>> wrote:
> Yes, I think I should too. But still no feedbacks :(
> 
> > On 03 Apr 2016, at 13:15, Björn Larsson <bjorn.x.lars...@telia.com 
> > <mailto:bjorn.x.lars...@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 references
> > in books about PHP, being the first piece of documentation. Two such
> > examples are:
> > - https://daveyshafik.com/archives/book/upgrading-to-php-7 
> > <https://daveyshafik.com/archives/book/upgrading-to-php-7>
> >  # In Appendix B
> > - http://www.php7book.com <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:
> >> 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> 
> >> <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@gmail.com 
> >>> <mailto:nikita@gmail.com>> wrote:
> >>>
> >>> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtko...@gmail.com 
> >>> <mailto:mtko...@gmail.com> <mailto:mtko...@gmail.com 
> >>> <mailto:mtko...@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 
> >>>

Re: [PHP-DEV] Tests for null coalescing assignment operator

[Midori Kocak]

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

> On 03 Apr 2016, at 13:15, Björn Larsson <bjorn.x.lars...@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 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:
>> 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
>> 
>>> On 25 Mar 2016, at 13:42, Nikita Popov <nikita@gmail.com> wrote:
>>> 
>>> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtko...@gmail.com 
>>> <mailto:mtko...@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 

[PHP-DEV] [RFC-DEV] A concern from @bwoebi about ??=

[Midori Kocak]

Hi,

I was asking   Why ??= can't be equal to $a = $a ?? $b; or $a ?? $a = $b;  and 
there was an example from @bwoebi. Can you please also check that? Here is the 
gist I wrote based on his code.

https://gist.github.com/midorikocak/c5325d19699254f6926af8eebdd1ee8a 


Yours,
Midori

[PHP-DEV] Tests for null coalescing assignment operator

[Midori Kocak]

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

> On 25 Mar 2016, at 13:42, Nikita Popov <nikita@gmail.com> wrote:
> 
> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtko...@gmail.com 
> <mailto:mtko...@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

[PHP-DEV] [RFC Accepted / Voting Closed] Null Coalescing Assignment Operator ??=

[Midori Kocak]

Dear All,

The voting of Null Coalescing Assignment Operator RFC 
https://wiki.php.net/rfc/null_coalesce_equal_operator 
 is accepted with 2/3 
majority, with 37 positive and 4 negative votes.

Thank you all of your votes and feedbacks.

Midori

Re: [PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

[Midori Kocak]

Thank you, I removed ‘equal’, you were right.

I could not find a way to change url. Also voting is already started.

Midori

> On 30 Mar 2016, at 22:22, Björn Larsson <bjorn.x.lars...@telia.com> wrote:
> 
> Hi,
> 
> Think the word equal should be removed from RFC name so
> it becomes "Null Coalescing Assignment Operator" or?
> 
> Also on the page https://wiki.php.net/rfc, possible to change
> the naming for "Null Coalesce Equal Operator" to reflect the
> title in the RFC even if the underlying URL itself is the same?
> 
> Regards //Björn Larsson
> 
> Den 2016-03-24 kl. 23:49, skrev Mutlu Kocak:
>> thank you so much. I updated the name.
>> 
>> On Thursday, 24 March 2016, Andrea Faulds<a...@ajf.me>  wrote:
>> 
>>> Hi Midori,
>>> 
>>> Midori Kocak wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I changed the name but I really don’ know how to change the url :)
>>>> 
>>>> Midori
>>>> 
>>>> 
>>> I don't think you can change the URL. In the past I've seen people create
>>> a new page in the /rfc/ namespace, copy the content there, and edit the old
>>> page to point to the new one. But the URL doesn't really matter, you don't
>>> need to change it. The original ?? RFC itself had a URL which was
>>> completely different from the title. :)
>>> 
>>> I appreciate that you changed the name. Did you mean to remove the "Equal"
>>> from the name, though? It's still there. (Sorry to bring this up again...)
>>> 
>>> Thanks!
>>> --
>>> Andrea Faulds
>>> https://ajf.me/
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit:http://www.php.net/unsub.php
>>> 
>>> 
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Combine ??= and ?:= assignment operator rfc's.

[Midori Kocak]

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>

> On 25 Mar 2016, at 13:42, Nikita Popov <nikita@gmail.com> wrote:
> 
> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtko...@gmail.com 
> <mailto:mtko...@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

[PHP-DEV] Combine ??= and ?:= assignment operator rfc's.

[Midori Kocak]

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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

[Midori Kocak]

Hi,

I changed the name but I really don’ know how to change the url :)

Midori

> On 24 Mar 2016, at 21:35, Andrea Faulds  wrote:
> 
> Hi,
> 
> Sara Golemon wrote:
>> Changing "equal" to "assignment" seems to have been the suggestion.
>> I've taken that into the short-ternary version.  And as a minor edit
>> (not worth closing/reopening vote) would recommend the same for null
>> coallesce.
>> 
>> -Sara
> 
> The other suggestion was to change "coalesce" to "coalescing", because the 
> former is a grammatical error I made when I wrote the original ?? RFC, 
> whereas the latter is the correct name.
> 
> Actually, if we go back to my original email on this subject:
> 
 Den 2016-03-13 kl. 02:59, skrev Andrea Faulds:
> I do have one thing to add, though. It's something of a nitpick, but the 
> name ought to be the "null-coalescing assignment operator". This would 
> follow the convention of referring to +=, -= etc. as compound/combined 
> assignment operators[1][2], not "equal" operators (which sounds more like 
> what == and === do, to me) and avoids the mistake ("coalesce" instead of 
> "coalescing") that I originally made in my RFC for ??.[3] I think that 
> RFC naming is important, because the name the author chooses for a 
> feature tends to be the one that ends up in the manual.
> 
> I already gave a suggestion for a name there: "null-coalescing assignment 
> operator".
> 
> It's not a big deal, though. :)
> 
> -- 
> Andrea Faulds
> https://ajf.me/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add spaceship assignment operator

[Midori Kocak]

actually it could be proposed to C in 1970 in a same manner for += operator by 
saying +== and +=== and also +. But hence Dennis Ritchie is dead and he 
accepted += as a founding father, we have no chance to ask him. Can we ask 
maybe to Bjarne Stroustrup as being one of another founding fathers? Is there 
anyone being in contact with him?


> On 24 Mar 2016, at 21:12, James Titcumb  wrote:
> 
> On 24 Mar 2016 19:43, "Mutlu Kocak"  wrote:
>> 
>> he is trolling :)
>> 
> 
> I wouldn't dismiss this idea straight off. I can see a lot of practical
> uses for chaining assignment operators, like:
> 
> $a !==<=> $b;
> 
> Expanded from:
> 
> $a = $a !== (($a <=> $b) === $b);
> 
> Which is something I often do in my production applications. In fact I
> typed this exact use case about 12 times just today.
> 
> It's a good, expressive way of simplifying code and increasing readability.
> This would really complete the language IMO.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

[Midori Kocak]

there were no suggestions. Do you have one?

> On 24 Mar 2016, at 16:36, Björn Larsson <bjorn.x.lars...@telia.com> wrote:
> 
> Den 2016-03-13 kl. 02:59, skrev Andrea Faulds:
>> Hi Midori,
>> 
>> Midori Kocak wrote:
>>> Forgive my rookieness and let me introduce my first RFC here: 
>>> https://wiki.php.net/rfc/null_coalesce_equal_operator 
>>> <https://wiki.php.net/rfc/null_coalesce_equal_operator>
>> 
>> I think this is a reasonable proposal. I had foreseen that we might add a 
>> ??= operator some day when I wrote the original RFC for the ?? operator.
>> 
>> I do have one thing to add, though. It's something of a nitpick, but the 
>> name ought to be the "null-coalescing assignment operator". This would 
>> follow the convention of referring to +=, -= etc. as compound/combined 
>> assignment operators[1][2], not "equal" operators (which sounds more like 
>> what == and === do, to me) and avoids the mistake ("coalesce" instead of 
>> "coalescing") that I originally made in my RFC for ??.[3] I think that RFC 
>> naming is important, because the name the author chooses for a feature tends 
>> to be the one that ends up in the manual.
>> 
>> Anyway, thank you for your RFC!
>> 
>> [1] http://php.net/manual/en/language.operators.assignment.php
>> [2] 
>> https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#compound-assignment
>> [3] https://blog.ajf.me/2015-12-07-poorly-named-rfcs
> 
> Any conclusion on naming of operator, remain or change?
> 
> Regards //Björn
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][Voting] Null Coalesce Equal Operator

[Midori Kocak]

Hi,

Remember Null coalesce Equal Operator ??= She is in voting phase now. :)

https://wiki.php.net/rfc/null_coalesce_equal_operator 


Thank you so much,
Midori
http://www.mynameismidori.com  

Re: [PHP-DEV] [RFC][Voting] Null Coalesce Equal Operator

[Midori Kocak]

Sorry I opened it now. You can vote.

> On 24 Mar 2016, at 16:06, Marco Pivetta <ocram...@gmail.com> wrote:
> 
> Hey Midori,
> 
> On 24 March 2016 at 16:02, Midori Kocak <mtko...@gmail.com 
> <mailto:mtko...@gmail.com>> wrote:
> Hi,
> 
> Remember Null coalesce Equal Operator ??= She is in voting phase now. :)
> 
> https://wiki.php.net/rfc/null_coalesce_equal_operator 
> <https://wiki.php.net/rfc/null_coalesce_equal_operator> 
> <https://wiki.php.net/rfc/null_coalesce_equal_operator 
> <https://wiki.php.net/rfc/null_coalesce_equal_operator>>
> 
> The poll doesn't seem to be open for voting.
> 
> Marco Pivetta 
> 
> http://twitter.com/Ocramius <http://twitter.com/Ocramius>  
> 
> http://ocramius.github.com/ <http://ocramius.github.com/>
>   
> 

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

[Midori Kocak]

Hi,

I fixed that, corrected some typos and closed voting.

Thank you for feedbacks,
Midori

> On 09 Mar 2016, at 19:55, Jakub Kubíček <kelerest...@gmail.com> wrote:
> 
> Hi Midori,
> 
> what about targetting this to the next PHP 7.x?
> 
> --
> Kubis
> On 10-Mar-2016 12:11 am, "Ryan Pallas" <derokor...@gmail.com 
> <mailto:derokor...@gmail.com>> wrote:
> On Wed, Mar 9, 2016 at 11:14 AM, Midori Kocak <mtko...@gmail.com 
> <mailto:mtko...@gmail.com>> wrote:
> 
> > Hi all,
> >
> > Remember my question about ??= operator?
> >
> > Forgive my rookieness and let me introduce my first RFC here:
> > https://wiki.php.net/rfc/null_coalesce_equal_operator 
> > <https://wiki.php.net/rfc/null_coalesce_equal_operator> <
> > https://wiki.php.net/rfc/null_coalesce_equal_operator 
> > <https://wiki.php.net/rfc/null_coalesce_equal_operator>>
> >
> 
> This looks great! I hope it makes it into the language for sure.
> 
> One comment though, voting section should not be opened until after the
> required discussion period.

[PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

[Midori Kocak]

Hi all,

Remember my question about ??= operator? 

Forgive my rookieness and let me introduce my first RFC here: 
https://wiki.php.net/rfc/null_coalesce_equal_operator 
<https://wiki.php.net/rfc/null_coalesce_equal_operator> 

Let me also include here the introduction I wrote:

Combined assignment operators are around since 1970's, appearing first in the C 
language. Consider the following code $x = $x + 3 that has the ability to be 
shortened into $x += 3. Hence PHP is a web focused language, ?? operator is 
used to check something's existence like $username = $_GET['user'] ?? 'nobody'; 
However due to common variable names are much longer than $username the use of 
?? self assignment, creates repeated code. 
$this->request->data['comments']['user_id'] = 
$this->request->data['comments']['user_id'] ?? ‘value’; It is also intuitive to 
use combined assignment operator null coalesce checking for self assignment.

I am sure there would be some language mistakes, please also forgive me for 
them too. 

Currently I created a working implementation here: 
https://github.com/php/php-src/pull/1795 
<https://github.com/php/php-src/pull/1795> you can see a terminal working with 
my implementation also here: http://imgur.com/zLlVFup <http://imgur.com/zLlVFup>

I hope I managed to write a simple and understandable RFC. Thank you all for 
your efforts.

Best Wishes,

Midori Kocak
Computer Scientist & Engineer / ZCPE
http://www.mynameismidori.com <http://www.mynameismidori.com/> 

Re: [PHP-DEV] Can you please give me karma? Understanding Karma as a Buddhist

[Midori Kocak]

Thank you very very much. I appreciate that. Now it’s the level 3.

Best wishes,
Midori



> On 09 Mar 2016, at 17:46, Ferenc Kovacs <tyr...@gmail.com> wrote:
> 
> 
> 
> On Wed, Mar 9, 2016 at 1:07 AM, Midori Kocak <mtko...@gmail.com 
> <mailto:mtko...@gmail.com>> wrote:
> Hello,
> 
> You remember my question?
> 
> A question about null coalescing operator..
> 
> $this->request->data['comments']['user_id'] = 
> $this->request->data['comments']['user_id'] ?? ‘value’;
> 
> …
> 
> And you remember my pull request? https://github.com/php/php-src/pull/1795 
> <https://github.com/php/php-src/pull/1795> 
> <https://github.com/php/php-src/pull/1795 
> <https://github.com/php/php-src/pull/1795>>
> 
> So now I created my wiki account after I figured what was the email thing. 
> And one friend suggested me to write here to ask to have Karma… So can you 
> please give me Karma?
> 
> Meanwhile I will be praying in front of my Buddha statue.
> 
> Midori
> http://www.mynameismidori.com <http://www.mynameismidori.com/> 
> <http://www.mynameismidori.com/ <http://www.mynameismidori.com/>>
> 
> 
> 
> done, feel free to ping me if you need further assistance.
> 
> -- 
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu <http://tyrael.hu/>

[PHP-DEV] Can you please give me karma? Understanding Karma as a Buddhist

[Midori Kocak]

Hello,

You remember my question? 

A question about null coalescing operator..

$this->request->data['comments']['user_id'] = 
$this->request->data['comments']['user_id'] ?? ‘value’;

…

And you remember my pull request? https://github.com/php/php-src/pull/1795 


So now I created my wiki account after I figured what was the email thing. And 
one friend suggested me to write here to ask to have Karma… So can you please 
give me Karma? 

Meanwhile I will be praying in front of my Buddha statue.

Midori
http://www.mynameismidori.com  

[PHP-DEV] Equal Null coalescing operator ??= https://github.com/php/php-src/pull/1795

[Midori Kocak]

Remember my question? 

$this->request->data['comments']['user_id'] = 
$this->request->data['comments']['user_id'] ?? ‘value’;

I want to check if some var is null and if the same var is null set the same 
var to ‘value’.

Hence I am repeating the same variable after the equal operator, this does not 
feels right.

So I feel that we need another operator like “??=“ similar to +=;

$this->request->data['comments']['user_id’]  ??= ‘value’. So if the var is null 
it’s set to ‘value’ and else stays the same.

I implemented it. Please check this here: 
https://github.com/php/php-src/pull/1795 


Midori

[PHP-DEV] Equal Null Coalescing Operator

[Midori Kocak]

A question about null coalescing operator..

$this->request->data['comments']['user_id'] = 
$this->request->data['comments']['user_id'] ?? ‘value’;

I want to check if some var is null and if the same var is null set the same 
var to ‘value’.

Hence I am repeating the same variable after the equal operator, this does not 
feels right.

So I feel that we need another operator like “??=“ similar to +=;

$this->request->data['comments']['user_id’]  ??= ‘value’. So if the var is null 
it’s set to ‘value’ and else stays the same.

Yours,
Midori Kocak
http://www.mynameismidori.com <http://www.mynameismidori.com/>

[PHP-DEV] Midori Kocak

[Midori Kocak]

A question about null coalescing operator..

$this->request->data['comments']['user_id'] = 
$this->request->data['comments']['user_id'] ?? ‘value’;

I want to check if some var is null and if the same var is null set the same 
var to ‘value’.

Hence I am repeating the same variable after the equal operator, this does not 
feels right.

So I feel that we need another operator like “??=“ similar to +=;

$this->request->data['comments']['user_id’]  ??= ‘value’. So if the var is null 
it’s set to ‘value’ and else stays the same.

Yours,
Midori Kocak
http://www.mynameismidori.com <http://www.mynameismidori.com/>