Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85313
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain yahoo.com designates 98.138.91.232 as permitted sender)
Date: Fri, 20 Mar 2015 18:16:36 +0000
Message-ID: <1858073635.20150320181636@yahoo.com>
To: Alex Bowers <bowersbros@gmail.com>
CC: internals@lists.php.net
In-Reply-To: <CAAn=CzVz_ULt9XHXRLNUv63v0TWSH3wvfO3NUOgA6b5zja=4-g@mail.gmail.com>
References: <CAAn=CzWySWQU1D93WA7L2eHvd31zogekEHmDUOsN7P6kBK4VrA@mail.gmail.com> 
  <550B5A81.1090706@gmail.com>
  <CAAn=CzUZPo=Yy79pRbot58nSR_tFqKYpd53kaAMbfxyUvz9Lwg@mail.gmail.com>
  <550B7189.4040608@gmail.com>
  <CAAn=CzUQc-av2dVBKwQg5xsCDiUXszfP1fWKVpBRMFNA3SjYEA@mail.gmail.com>
  <7486C296-7535-4633-AFE2-02E7BBC67BC5@gmail.com>
  <CAAn=CzXR=cU8Pq4wzNQXKLhqDt9WOF3CJfk2B=3z8DBtQhVvCg@mail.gmail.com>
  <550C1176.9050307@gmail.com>
  <CAAn=CzWzKXSW0m+CrjzAT+Lq-j07M_V-WnBAvwSDhqLKCo=OiA@mail.gmail.com>
  <550C1AE4.8090607@gmail.com>
  <CAAn=CzVGpuDJWA7zH7yMwYRQPJuqOKUJ+gbSebsHTUgwoc0wNA@mail.gmail.com>
  <550C1DEC.5060706@gmail.com>
  <CAAn=CzXBSqtTm_ZSA3GgSfC3sqi0jyX_AXS=q=PE0FcCoPGYCw@mail.gmail.com>
  <15030741.20150320143622@yahoo.com>
  <CAAn=CzXvR8djpxzcO46X_4QCvdx7xrg7-uLE4m1=_izH3ypZUw@mail.gmail.com>
  <114590901.20150320170242@yahoo.com>
  <CAAn=CzVz_ULt9XHXRLNUv63v0TWSH3wvfO3NUOgA6b5zja=4-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: vikhudec@yahoo.com (Vik Hudec)

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