Re: RFC - Array slice syntactic sugar
| From: | Vik Hudec | Date: | Fri, 20 Mar 2015 18:16:36 +0000 |
| Subject: | Re: RFC - Array slice syntactic sugar | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-85313@lists.php.net to get a copy of this message | ||
Alex,
On Fri, 2015-03-20, at 17:19, Alex Bowers wrote:
> When you say restrict to one each. Do you mean one for strings and one for
> arrays?
Yes, that's what I mean. I would propose square brackets for array offsets,
and curly braces for strings.
> If so I'd have to disagree with this, since having the same operation
> available to both is less likely to give mistakes. Can you give an example
> of an actual benefit for this? Since this would cause a backwards
> incompatible change. I can't imagine many places if any use the curly
> brackets for arrays or strings, but since it exists there may be people
> using it. Changing the behaviour of this to only work for one of the two
> options seems unnecessary in the name of making code slightly more
> apparent on initial reading. But variable names and so on should be used
> to help distinguish from array or strings anyway.
Yes, I'm very conscious of the substantial BC break, which is why I would
target PHP 8 (or even 9, following a deprecation cycle). I guess you and I
disagree on the benefits of syntax that is more self-documenting. The vast
majority of PHP developers don't use variable names to indicate data types;
the only common convention I've seen is for arrays' names to be pluralized
(ie. $items, $rows etc.), but this doesn't really help. Often when less-
experienced developers come across code that uses subscript syntax on a
variable, they typically assume that the variable is an array (since string
offsets are so much less common), and in doing so, introduce bugs. If the
use of curly-braces was mandatory for string offsets, then code like this
couldn't be mistaken for anything else.
Vik