Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85310
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <114590901.20150320170242@yahoo.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>
Date: Fri, 20 Mar 2015 17:19:51 +0000
Message-ID: <CAAn=CzVz_ULt9XHXRLNUv63v0TWSH3wvfO3NUOgA6b5zja=4-g@mail.gmail.com>
To: Vik Hudec <vikhudec@yahoo.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=089e01493d5c4427430511bb86b9
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: bowersbros@gmail.com (Alex Bowers)

--089e01493d5c4427430511bb86b9
Content-Type: text/plain; charset=UTF-8

When you say restrict to one each. Do you mean one for strings and one for
arrays?

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.
 On 20 Mar 2015 17:02, "Vik Hudec" <vikhudec@yahoo.com> wrote:

> Hi Alex,
>
> On Fri, 2015-03-20, at 14:52, Alex Bowers wrote:
>
> > But I don't think we should only match {} for strings and [] for arrays,
> > that seems broken to me.
>
> > Maybe you misunderstand me, I am against using two syntaxes for different
> > things.
>
> Based on your reply; yes, I'm definitely misunderstanding! In summary, we
> already have two different operations:
>
> (1) Accessing an array's element using subscript notation, eg:
> $foo = array('bar'); var_dump($foo[0]); // string(3) "bar"
>
> (2) Accessing a string's character using subscript notation, eg:
> $foo = 'bar'; var_dump($foo[0]); // string(1) "b"
>
> And we already have two different syntaxes: $var[$offset] and
> $var{$offset}.
>
> So we have two syntaxes that each perform two operations. Are we in
> agreement that this isn't a good thing?
>
> Sorry that this is all a little off-topic, but I'm interested in people's
> opinions because I'm considering a future RFC. My proposition would be to
> restrict the two subscript syntaxes to one operation each. And if your
> slice
> sugar RFC aims to augment the functionality of either one or both of these
> syntaxes, then that's relevant to me.
>
> Vik
>
>

--089e01493d5c4427430511bb86b9--