Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91215
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
To: internals@lists.php.net
References: <56A3A01F.1020500@php.net> <56BB4A5F.3060906@php.net>
 <56BC29C8.9070308@gmail.com>
 <CAGa2bXaJ1dphqr8MXWXtUkicx1eP-o21SLQtf_MxoVb2o823wg@mail.gmail.com>
 <56BC3372.1010308@gmail.com>
 <CAGa2bXbWnLkp3mfQBNbOxJxy8U0hNBA7e_RbiekJrfC4YFEgbg@mail.gmail.com>
 <56BCCDD3.8030402@gmail.com>
Message-ID: <56BDABB1.5020901@lsces.co.uk>
Date: Fri, 12 Feb 2016 09:53:53 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <56BCCDD3.8030402@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: lester@lsces.co.uk (Lester Caine)

On 11/02/16 18:07, Stanislav Malyshev wrote:
>> It does not worth the effort having other RFCs for
>> >  - $str{} = 'string'
> Correct, because nobody needs it and it is a bad idea.
> 
>> > I agree small changes are easier to review, but it may leave lots of
>> > obvious inconsistency in PHP. We have too many of them already.
> If you have examples of "obvious inconsistency", name them and we will
> discuss it. {} is not such example.

One thing that everybody agrees on is that the procedural API for arrays
is 'somewhat clunky'? But fixing it by renaming, changing parts to
better match other parts and so on has hit brick walls because of BC.
That an OO array API that is consistent and expandable has also been
agreed in the past, but no one has the time or 'urge' or pursue that
path? Along with the Unicode string OO extension?

So do we not need perhaps a clean road map on the procedural API to
establish just where things like 'negative string offsets' fit into the
whole picture? That array and string API's are now inextricably linked
had been pointed out in the past and we now have to live with the
results, but a PHP8 change may be to split the two syntaxes so one can
look at code and not have to work out if some variable buried in a
cleaver piece of software is in indexed string or simply an array element?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk