Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91099
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56AFC8CC.6040201@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>
	<56AFC8CC.6040201@gmail.com>
Date: Sat, 6 Feb 2016 16:16:31 +0100
Message-ID: <CAF+90c-XQOpK9Gm6BOv-JndZxXThVwxtU2rqLAMA2XpBz4w01w@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d07ccd969bb052b1b73b7
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113d07ccd969bb052b1b73b7
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 1, 2016 at 10:06 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> 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.
>

What are these subtle differences?


> > 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.
>

I agree that different things should use different syntax. However, the
point here is that all of array access, ArrayAccess and string offset
access are really the same thing and as such should also use the same
syntax. Array construction and destructuring on the other hand are
different concerns from array access and as such do use a different syntax
(even though it might reuse a token, I do not see a potential for
confusion).

Arguing that string offset access requires a different syntax than array
access to me is the same as arguing that reading an array offset and
reading an offset of an ArrayAccess object also require different syntax.
Sure there are subtle differences between how plain array access works and
how ArrayAccess works (especially once you get around to nested
ArrayAccess), but at its core it's the same operation: Getting an element
from a vector or map like structure using an offset or key. String offset
access falls into the same category.

There is value in emphasizing the difference of two operations by using
different syntax, but there is also much value in using one, and only one,
syntax to cover a set of very tightly related operations, rather than
branching off in a dozen ways in an attempt to accurately capture all
possible idiosyncrasies.

In any case, while this is no doubt an interesting question, and one we
should resolve, it is tangential to this RFC and this RFC should make no
recommendations either way. I would prefer not to be forced to vote against
this RFC due to the inclusion of the unnecessary and unrelated "In the
documentation" section. A different proposal should concern itself with
this matter.

Thanks,
Nikita

--001a113d07ccd969bb052b1b73b7--