As mentioned earlier: In hack (hhvm), operators like +=, *= etc do allow the left side to be undefined. (However, ++ and -- do not allow the left side to be undefined.)
I wonder if this is intended, or by accident. On 20 January 2018 at 06:47, Andreas Hennings <andr...@dqxtech.net> wrote: > On 20 January 2018 at 04:29, Aidan Woods <aidantwo...@gmail.com> wrote: >> On 20 January 2018 at 01:25, Andreas Hennings <andr...@dqxtech.net> wrote: >>> >>> On 19 January 2018 at 16:12, Sara Golemon <poll...@php.net> wrote: >>> > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker <cmbecke...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
