Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91110
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
To: internals@lists.php.net
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>
 <CAF+90c-XQOpK9Gm6BOv-JndZxXThVwxtU2rqLAMA2XpBz4w01w@mail.gmail.com>
Message-ID: <56B877AD.4020105@gmail.com>
Date: Mon, 8 Feb 2016 11:10:37 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c-XQOpK9Gm6BOv-JndZxXThVwxtU2rqLAMA2XpBz4w01w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: rowan.collins@gmail.com (Rowan Collins)

Nikita Popov wrote on 06/02/2016 15:16:
> 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.

There is one case where it is highly relevant - if the aim in the future 
is to make string offsets behave more like array offsets, then this RFC 
should be rejected. My reasoning being that negative offsets are legal 
in array access, with a different meaning, so adding this feature 
increases the difference between string and array indexing.

Many of the other differences are - in theory at least - resolvable. 
e.g. $string[1]++ could be equivalent to $temp = $string[1]; $temp++; 
$string[1] = $temp;

If making string access similar to array access is a lower priority than 
adding features such as the one in this RFC, then the case for switching 
to {} is strengthened, but not conclusive.

Regards,
-- 
Rowan Collins
[IMSoP]