Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107185
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 17 Sep 2019 10:42:53 +0200
References: <CACXBjuh_-Q6fMxQN8ddYcQQOjTU6RAZPNp9uMfg01LjvZt80ug@mail.gmail.com>
 <CAF+90c_pivhDhWbFs-qwbvSEGKU41xX6F5r3idTOwh_2f6R+0Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAF+90c_pivhDhWbFs-qwbvSEGKU41xX6F5r3idTOwh_2f6R+0Q@mail.gmail.com>
Message-ID: <E1B2D96D-AF67-46B4-9978-5195AF94E174@cschneid.com>
Subject: Re: [PHP-DEV] Evolving PHP
From: cschneid@cschneid.com (Christian Schneider)

Am 16.09.2019 um 21:32 schrieb Nikita Popov <nikita.ppv@gmail.com>:
> Thanks for chiming in Rasmus. A few brief thoughts on recent =
discussions:
>=20
> * The RFC process encompasses language changes (breaking or =
non-breaking),
> as well as policy and process decisions. We have a very wide selection =
of
> precedent cases that affirm this.

It feels to me that it gradually changed into that.
And while the initial RFCs seemed innocuous policy and process decisions =
they are now used as a precedent. Should the first non-technical RFCs =
have been examined more closely due to this? Maybe. But just because it =
wasn't done doesn't mean the situation cannot be reassessed again. Just =
because there are now policy and process RFCs does not mean we could =
take a step back and limit RFCs again.

Just to be clear: I'm not demanding anything, I'm just wary of the =
"that's just the way it is, look at previous examples" argument.

> * The "undefined variables" vote that sparked the current controversy
> currently sits at 29 in favor of exception and 20 against. That's
> significantly below the acceptance threshold for RFCs. Things are =
working
> as they should: The question has been discussed, put up to vote, and =
the
> vote has decided against this course of action (as of this writing, =
though
> I expect this to be representative of the final result.)

I agree but disagree at the same time:
First of all the discussion was unpleasant which I don't see as "working =
as it should".

And while I do think the discussion about undefined variables did clear =
some things up I also think it distracted from other points in the RFC.
I personally chose my battle to focus on undefined variables because it =
was the biggest pain point. But there are lots of other conversions to =
Exceptions which were left in the main bulk of things even though they =
have similarities with undefined variables. A foreach over null might =
indicate a problem but it is well defined and might occur in correctly =
working code.
Yes, a warning might be appropriate but stopping execution is a =
different beast again.

> * As a personal failure, I should have made the voting option for =
"undef
> vars throw exception" be "undef vars throw warning in PHP 8 and =
exception
> in PHP 9", which would have provided for a long-term migration =
timeline for
> affected code. I apologize for pushing an unnecessarily aggressive =
option
> here.

Maybe it was quite the opposite: It forced the discussion to happen now. =
And while it was unpleasant I'm worried that otherwise it would have =
legitimised making undefined variables an Exception because "we already =
promoted it to a warning so we all agree that it is bad" which would be =
wrong.
Sure, maybe by the time PHP 9 comes around people agree that an =
Exception is the right thing to do. But using warnings as a door-opener =
for exceptions is something to be considered very carefully.

- Chris