Re: [PHP-DEV] null coalesce addition assignment operator ??+=
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 wrote: > On 20 January 2018 at 04:29, Aidan Woods wrote: >> On 20 January 2018 at 01:25, Andreas Hennings wrote: >>> >>> On 19 January 2018 at 16:12, Sara Golemon wrote: >>> > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker >>> > 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
Re: [PHP-DEV] null coalesce addition assignment operator ??+=
On 20 January 2018 at 04:29, Aidan Woods wrote: > On 20 January 2018 at 01:25, Andreas Hennings wrote: >> >> On 19 January 2018 at 16:12, Sara Golemon wrote: >> > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker >> > 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
Re: [PHP-DEV] null coalesce addition assignment operator ??+=
On 20 January 2018 at 01:25, Andreas Hennings wrote: > On 19 January 2018 at 16:12, Sara Golemon wrote: > > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker > 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? Furthermore, I think you can generalise this in user-land and end up with a better result. 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 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 Kind regards, Aidan
Re: [PHP-DEV] null coalesce addition assignment operator ??+=
On 19 January 2018 at 16:12, Sara Golemon wrote: > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker > 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Big_Endian problem
On Fri, Jan 19, 2018 at 4:04 PM, Sam Ding wrote: > The test case ext/standard/tests/general_functions/bug72300.phpt is failed > on s390x. > The function "ignore_user_abort" returns "256" on s390x, and "1" on x86_64 > after "ignore_user_abort" is set to true; > The root reason is because of Big_Endian on s390x. > Here is the C code: ext/standard/basic_functions.c > b/ext/standard/basic_functions.c:5641 > >old_setting = (unsigned short)PG(ignore_user_abort); > //php_core_globals.ignore_user_abort, "x /2b" shows its > value : "0x01 0x00" on both platforms > That specific line isn't the problem, as it's just cashing a short to an unsigned short, which is legal and not problematic for any endianness. The actual problem is that PG(ignore_user_abort) is declared as a short, but its INI handler method is defined as OnUpdateBool (which of course, only operates on a single byte). > Does PHP interpreter support Big_Endian? Are there any existing > macros/functions to deal with Big/Little Endian? > Yep. And if things break on s390x, please let us know! I'll put together a fix for this over the weekend and apply it to 7.0 and later versions. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation
Hi again, On Fri, Jan 19, 2018 at 9:30 PM, Niklas Keller wrote: > > I think we only have to bump the minimum version once 7.4 is out, because > only 7.4 will change the default. You only get a deprecation notice now, > which is totally fine. > I disagree that it's totally fine. I mean, it's technically fine (it still works), but in principle it's not ok to have no option of writing code that doesn't trigger warnings and notices. Certainly not for the possible entirety of 7.2 and 7.3 life-cycles. And yes, on one hand it's the server admins' fault, but all that does is delegating to framework/library authors the responsibility to explain the problem to clueless users. It's easy to explain that they can't use feature X because they don't have Intl (which you can point to on php.net), they should at least know what a PHP extension is. Not so easy to explain they'll always get an E_DEPRECATED notice because somebody set them up with a bad version of some acronym they've never even had to know of. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Big_Endian problem
Hi all, The test case ext/standard/tests/general_functions/bug72300.phpt is failed on s390x. The function "ignore_user_abort" returns "256" on s390x, and "1" on x86_64 after "ignore_user_abort" is set to true; The root reason is because of Big_Endian on s390x. Here is the C code: ext/standard/basic_functions.c b/ext/standard/basic_functions.c:5641 old_setting = (unsigned short)PG(ignore_user_abort); //php_core_globals.ignore_user_abort, "x /2b" shows its value : "0x01 0x00" on both platforms Does PHP interpreter support Big_Endian? Are there any existing macros/functions to deal with Big/Little Endian? Thanks, Sam Ding
Re: [PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation
2018-01-19 20:09 GMT+01:00 Andrey Andreev : > On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon wrote: > > (Seriously though, who's on php 7.2, but hasn't updated ICU for that > > long?) > > Probably nobody yet. The issue was uncovered in code that assumed the > constant was available on 5.4+, as noted in the manual, but it turned > out there's people on 5.6, 7.0 who don't have it. Also PHP 7.1: https://github.com/zendframework/zend-validator/issues/193 We also had an issue report, but I can't find it currently, forgot to link it from the commit: https://github.com/amphp/uri/commit/2de94666447319d8695f2d11f3f005d5fee0876a I think we only have to bump the minimum version once 7.4 is out, because only 7.4 will change the default. You only get a deprecation notice now, which is totally fine. Regards, Niklas
Re: [PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation
On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon wrote: > (Seriously though, who's on php 7.2, but hasn't updated ICU for that > long?) Probably nobody yet. The issue was uncovered in code that assumed the constant was available on 5.4+, as noted in the manual, but it turned out there's people on 5.6, 7.0 who don't have it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation
On Fri, Jan 19, 2018 at 1:11 PM, Andrey Andreev wrote: > My immediate thought is to simply bump the ICU version requirement, > but I have no idea what kind of an impact that would have. > According to that page, 46 is seven years old. I for one am 100% okay with making that the minimum, though not necessarily because of the IDNA issue. If someone on a system running 46 needs to use the idn functions with php 7.2, then they are motivated to bug their admin. (Seriously though, who's on php 7.2, but hasn't updated ICU for that long?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation
Hello, It seems that an important detail was missed in the RFC to deprecate INTL_IDNA_VARIANT_2003 in PHP 7.2.0 (and later remove it). The only other option available - INTL_IDNA_VARIANT_UTS46 - may not be available at all, as PHP has ICU 4.0 as its minimum requirement, but support for UTS#46 was introduced by ICU 4.6 ... As a result, there may be systems where having a clean call to idn_to_ascii(), idn_to_utf() is impossible. I'm all for following deprecations by upstream, but I didn't find any mention of this scenario in the discussions. I'm assuming nobody has considered it and we're in a bit of a mess right now, so ... My immediate thought is to simply bump the ICU version requirement, but I have no idea what kind of an impact that would have. [1] RFC: https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003 [2] ICU 4.6 release: http://site.icu-project.org/download/46 Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] null coalesce addition assignment operator ??+=
On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker 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 . -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
