Re: [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

From: Date: Fri, 05 Jul 2019 08:40:02 +0000
Subject: Re: [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-106153@lists.php.net to get a copy of this message
Thanks for taking the time to push forward this RFC. I found the earlier discussion at https://externals.io/message/104744, which I hadn't seen. Like others, I would have chosen to keep {} for string offsets to make it clearer, though I have not used {} in my code for a decade. Was any consideration given to a split vote, voting on the array and string deprecations separately? For others interested, the history of this deprecation going back to 2005 is found at https://externals.io/message/38153
I have the same question regarding split vote. In my eyes the array case is a no-brainer, but for string access maybe not...
Good question. I did consider whether it would make sense to only deprecate curly brace offset access for arrays and not strings. The problem with this is that it wouldn't solve the issue of confusion outlined in the RFC.
Syntax (and depreciation) checks on compile time.It's make impossible to separate arrays and strings because of PHP nature.
Would it be possible to compare the string access only for both curly & straight braces and the same for array access?
I updated my script to list all the unique variable names referenced in the output of Nikita's analysis of the top 2k Composer packages:> https://gist.github.com/theodorejb/ba35fc8f72df8823e07c5f3b51870e00.
The most frequent variable name is $string, and from numerous other variable names it does seem that the majority of curly brace usages are on strings (other frequent variable names include $code, $Bytestring, $chrs, $text, $str, $numberstring, and many similar examples). I also dug into the repositories for a bunch of the packages, and most of the curly braces uses appear to be in older code without any type declarations (which may explain why so many variable names include a type).
Also:'phpoffice/phpexcel' => 219, abandoned 'tecnick.com/tcpdf' => 74, abandoned 'yiisoft/yii' => 64, deprecated, only security fixes'zendframework/zendframework1' => 37, abandoned'dflydev/markdown' => 22, abandoned 'picqer/php-barcode-generator' => 63, inherits code from 'tecnickcom/tcpdf' 'milon/barcode' => 89, inherits code from 'tecnickcom/tcpdf''lukasreschke/id3parser' => 78, inherits code from 'james-heinrich/getid3'etc. Inherited code in general means that it is not author decision but only copy paste.

« previous php.internals (#106153) next »