Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessingarray elements and string offsets

This is only part of a thread. view whole thread
  106135
July 3, 2019 15:25 phpmailinglists@gmail.com (Peter Bowyer)
Hi Andrey,

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

Peter
  106146
July 4, 2019 22:26 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-07-03 kl. 17:25, skrev Peter Bowyer:
> Hi Andrey, > > 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 > > Peter > Hi,
I have the same question regarding split vote. In my eyes the array case is a no-brainer, but for string access maybe not... r//Björn L
  106147
July 5, 2019 01:48 theodorejb@outlook.com (Theodore Brown)
On Thu, July 4, 2019 at 5:26 PM Björn Larsson larsson@telia.com> wrote:

> Den 2019-07-03 kl. 17:25, skrev Peter Bowyer: > > > 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 > > Hi, > > 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. Unless the bracket syntax for string offset access was also deprecated, users would still be left to question whether the curly brace syntax behaves differently in certain circumstances, if one alternative performs better than the other, if there is a scoping related difference, or when the curly brace syntax should be used instead of the normal bracket syntax for string offset access.
> 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). Best regards, Theodore
  106183
July 8, 2019 18:32 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-07-05 kl. 03:48, skrev Theodore Brown:
> On Thu, July 4, 2019 at 5:26 PM Björn Larsson larsson@telia.com> wrote: > >> Den 2019-07-03 kl. 17:25, skrev Peter Bowyer: >> >>> 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 >> Hi, >> >> 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. > > Unless the bracket syntax for string offset access was also > deprecated, users would still be left to question whether the curly > brace syntax behaves differently in certain circumstances, if one > alternative performs better than the other, if there is a scoping > related difference, or when the curly brace syntax should be used > instead of the normal bracket syntax for string offset access. > > >> 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). > > Best regards, > Theodore
Hi, Thanks for the clarification. My concern regarding the vote is that string curly braces is swept along the vote for array curly braces, since the last one is so obvious to deprecate. So separate votes would make it clearer. One could add that keeping string curly braces could help removing confusion when reading code ;-) For instance is $var[7] an array or string access. Having string curly braces gives the programmer one more tool to improve readability. r//Björn L