Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91050
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.179 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>
References: <56A3A01F.1020500@php.net>
 <CAF+90c-rh5uss4xTjbvvjr6PO5iAYaQ=DQRbVNr+h1kMm8HW9A@mail.gmail.com>
 <56AE8735.4070901@gmail.com>
 <CAF+90c8khmu=fxUzP-JX1PGjcgKzvhd6W+bsaZUk_OUALkgrig@mail.gmail.com>
Cc: Internals <internals@lists.php.net>
Message-ID: <56AFC8CC.6040201@gmail.com>
Date: Mon, 1 Feb 2016 13:06:20 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c8khmu=fxUzP-JX1PGjcgKzvhd6W+bsaZUk_OUALkgrig@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I strongly disagree with this. $str[$offset] is well-recognized,
> generally understood syntax that does not require familiarity with
> language peculiarities. $str{$offset} might be clear to a Perl
> programmer, but to anyone else this is just guesswork, with a typo being
> a reasonable assumption.

The problem is that while it is generally understood, it's generally
understood wrongly. $str[$offset] is not the same operation as
$array[$offset]. There are many subtle differences. So while at the
first sight it's similar, it leads to "understanding" that is only going
to harm one in the future, when it turns out you really had wrong idea.
I think it's much better to instill the right idea from the start, even
if it means one has to take a brief look in the manual. String offset is
*not* the same as array access.

> We should be deprecating this alternative syntax instead of recommending
> its use. I was under the impression that we *were* already discouraging
> its use and it has already been temporarily deprecated.

I think deprecating it was a mistake and give how much semantic load []
carries - array access, array constructor, now there's proposal to make
it used in deconstructing too - adding string offset to it looks like
bad idea. Different things should use different syntax, as much as possible.

-- 
Stas Malyshev
smalyshev@gmail.com