Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.43 cause and error)
MIME-Version: 1.0
In-Reply-To: <CALtMV+NBrwa5Z13Hbx5DKxTzWBuOgDyxP6KpomdcjQ0mpzMSTA@mail.gmail.com>
References: <CAH0Uv3HUMXOYeGNPFDfKdHpMtfoAdQTgZxVSU+0vNvv6+jynYw@mail.gmail.com>
 <9a4e54d1-10d8-889e-e705-fe473e2e3713@gmail.com> <3aa2372c-c31a-d41a-f455-35ce400b382b@gmx.de>
 <CAESVnVqOSX2iaTz4B-QFc5RZuzfj3-+mm+ce0v1m8JkyWo4N1w@mail.gmail.com>
 <CAH0Uv3FB8gKkoxhXz-Dyj5AoVSPZEZ-XnfY6qOiR==8aZhsbGg@mail.gmail.com> <CALtMV+NBrwa5Z13Hbx5DKxTzWBuOgDyxP6KpomdcjQ0mpzMSTA@mail.gmail.com>
Date: Sat, 20 Jan 2018 06:47:09 +0100
Message-ID: <CAH0Uv3EJyYoJKX-6sQnS1SJ7HRNExKE5b9zRiy5U269jRerZeQ@mail.gmail.com>
To: Aidan Woods <aidantwoods@gmail.com>
Cc: Sara Golemon <pollita@php.net>, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] null coalesce addition assignment operator ??+=
From: andreas@dqxtech.net (Andreas Hennings)

On 20 January 2018 at 04:29, Aidan Woods <aidantwoods@gmail.com> wrote:
> On 20 January 2018 at 01:25, Andreas Hennings <andreas@dqxtech.net> wrote:
>>
>> On 19 January 2018 at 16:12, Sara Golemon <pollita@php.net> wrote:
>> > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker <cmbecker69@gmx.de>
>> > wrote:
>> >> On 18.01.2018 at 23:58, Stanislav Malyshev wrote:
>> >>
>> >>>> I propose even more such operators:
>> >>>> null coalesce addition assignment ??+= (for strings and numbers)
>> >>>> null coalesce subtraction assignment ??-=
>> >>>> null coalesce increment ??++
>> >>>> null coalesce decrement ??--
>> >>>> null coalesce multiplication assingment ??*=
>> >>>
>> >>> I think this is taking it too far. If you want language like that, you
>> >>> always have APL :)
>> >>
>> >> Why do we discuss extensions to an operator which has still (after
>> >> nearly two years) not be implemented due to implementation
>> >> difficulties?
>> >>
>> > Am I the only one who looked at the original post and assumed he was
>> > taking the piss?
>> > Similar to the jokes about spaceship assignment <=>= and
>> > equality/identicality assignment === (not to be confused with
>> > identical non-assign, which is ===) and ====.
>>
>> I can definitely say it was not a joke.
>> I can see myself and others use the ??+= and also ??++, and would have
>> used them in the past, if they had been available.
>> The others, I don't care as much.
>>
>> For me, a good enough conclusion of this conversation would be one of:
>> A: Yeah seems useful, but let's wait (or work) until ??= is
>> implemented and released, and observe how it is being used.
>> B: No one will ever use it, and it would hurt the language.
>>
>
> Going by the example, would this operator's behaviour be a little confusing?
>
> As I understand it the (maybe) upcoming `??=` operator will assign in the
> case that the lhs is *not defined*.
> But for `??+=` incrementing appears to be desired when the lhs *is defined*,
> (with assignment to the operator related identity element in the case that
> the lhs is undefined).
>
> While the use-case seems to add value in the scenario, I think it is
> possibly
> inconsistent with the way `??=` works?

I think it depends how you see it.

// shortcut
return $x ??= 5;
return $y ??+= 5;

// spelled out, looks inconsistent
return isset($x) ? $x : ($x = 5);
return isset($y) ? ($y += 5) : ($y = 5);

// spelled out, looks a bit more consistent (despite being broken)
return (isset($x) ? $x : ($x = 5));
return (isset($y) ? $y : ($y = 0)) += 5;  // invalid code, because
ternary is not a valid lhs.

The line is invalid, but shows the mental model or the excuse that
allows us to claim this is consistent.

But yeah, I can see how someone would expect a different behavior:

return isset($x) ? $x : ($x = 5);
return isset($y) ? $y : ($y += 5);

This would not make sense or be useful because:
For $y === NULL, this would evaluate as
return $y = NULL + 5:

Still, your argument raises a valid concern that the operator might be
misunderstood.



If we get ??=, I previously thought we could use it like this, to
replicate ??+=:

return ($y ??= 0) += 5;

Unfortunately, I think we can expect that ??= won't be a valid lhs,
because neither is *= or += etc.
E.g. this is invalid:
($y *= 3) += 1;
https://3v4l.org/oKIkl


>
> Furthermore, I think you can generalise this in user-land and end up with a
> better result.

comments below.

>
> When dealing with structured data (i.e. when you expect strings mapping to
> ints in your example) you may consider writing a simple class for making
> such type guarantees. Something simple like https://3v4l.org/5Sh04 would
> produce the desired result, and let you obtain the result in one line at
> point
> of use.
>
> Nothing ties you into using a class for the storage though, you could
> simplify
> even further and just create some abstract class representing an "array
> toolbox"
> for these kind of operations, e.g. https://3v4l.org/ZJcom
> So that the array initialisation, foreach loop, and operator are replaced
> with a
> single line again at point of use (after defining the arraytools class
> once).
>
> If you wanted it to work more generally, you could use a reference to delay
> lookup, and keep your current code structure https://3v4l.org/TJYhq

I was never a big friend of those array functions with callback
arguments, which force me to remember a signature.
I find a simple foreach() to be more readable. I think it is also faster.

So yeah, I prefer this example to the previous ones.

>
> If you wanted it to look the part you could even sneak some unicode symbols
> in to make it look like some sort of operator ;-) https://3v4l.org/MVT85

Looks interesting, but people have to type this! So, no unicode symbols.

>
> Kind regards,
> Aidan

If I were to do it in userland, it would either be
- in my own custom library or application, where it would not be used
by others, or
- in a shared package, which other packages could add as a dependency.

I think usually people will decide against adding a dependency for a
bit of syntax sugar.
E.g. if the existing null coalesce operator was provided as a userland
solution, I don't think this package would have become popular.
Instead, code that uses such a package would become less readable, not
more readable.

I remember when I was dealing with CiviCRM, which had those "something
smart with arrays" functions.
Maybe they had the same purpose as what we discuss here, or they did
something else.
The result was: Whenever I had to look at such a call, I was confused,
and had to re-confirm what it does.
Maybe it could have gotten used to it, but I did not spend that much
time with CiviCRM.

Nowadays I prefer native features, even if they are more verbose.
They also need to be learned / gotten used to, but at least this
experience will be the same for everyone.

I also often do these kinds of array-crunching operations in throwaway
code for debugging, e.g. to build a statistic for a bunch of values.
In such cases I don't want to add a new dependency to the application.