Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91197
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.182 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <56BC3372.1010308@gmail.com>
References: <56A3A01F.1020500@php.net> <56BB4A5F.3060906@php.net>
 <56BC29C8.9070308@gmail.com> <CAGa2bXaJ1dphqr8MXWXtUkicx1eP-o21SLQtf_MxoVb2o823wg@mail.gmail.com>
 <56BC3372.1010308@gmail.com>
Date: Thu, 11 Feb 2016 20:12:31 +0900
Message-ID: <CAGa2bXbWnLkp3mfQBNbOxJxy8U0hNBA7e_RbiekJrfC4YFEgbg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>, 
	Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Stas,

On Thu, Feb 11, 2016 at 4:08 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> RFC must maintain consistency across existing features/specifications,
>
> There's a lot of things people call "consistency", apparently. I don't
> see inventing new syntax for doing concatenation to have anything to do
> with consistency.
>
>> make things worse certainly. Making patch and/or RFC simple is not the
>> reason why we have RFC, but to have full featured/discussed/consistent
>
> To have simple patch is not really why we have RFCs, of course. But
> having simple (or not overly complex) RFC is a sign of a good RFC. On
> the contrary, overly complex and convoluted ones make it hard to review
> them and usually lead to unintended consequences and mistakes since it
> is hard to predict the outcomes in such complexity.
>
>> Aren't we better to have consistent/complete RFCs almost always?
>
> Since everybody defines "consistent" to mean pretty much anything they
> want, there's no answer to this question.

Since Francois removed the section, it's not important for this discussion
anymore.

Anyway, all of us know that main source of complaints about PHP is lack
of consistency. Inconsistent APIs across modules are acceptable. It's
modules after all. However, basic language constructs like [] and {} are
better to have  predictable/consistent behaviors. i.e. how it  works, raised
errors.

This RFC improves inconsistent behaviors a lot. Why not to add
$str{} = 'string'? It's not complex nor BC as it raises syntax error currently.
It does not worth the effort having other RFCs for
 - $str{} = 'string'
 - error level/message tweaks. i.e. Raise the same error for similar situations.
 - and so on.

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.
Making RFC and pass the vote is not easy task. Authors may not have
time for RFCs for clean ups.

Every each one of RFC should try to reduce number of obvious inconsistency
as much as possible, IMHO. Otherwise, we end up with increasing them.
Code review being a little more difficult is not too important issue,
but leaving
behind obvious inconsistency is.

Let's concentrate improvements to be complete. We have plenty of time
before 7.1 release.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net