Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106966
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net>
In-Reply-To: <076701d56978$86020910$92061b30$@php.net>
Date: Thu, 12 Sep 2019 16:58:36 +0200
Message-ID: <CADyq6sK4HektgfDpCCFR3=bumyPaf9vn=-WdvaboHybBQKd53g@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000faa9e905925c5f4e"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: ocramius@gmail.com (Marco Pivetta)

--000000000000faa9e905925c5f4e
Content-Type: text/plain; charset="UTF-8"

Hi Zeev,


On Thu, Sep 12, 2019 at 4:44 PM Zeev Suraski <zeev@php.net> wrote:

> I was really really hoping that we will avert having to dive into this and
> instead go for the alternative solution that was proposed of changing
> default php.ini error levels.  But since the RFC went on to a vote - we
> need
> to make something clear.
>
>
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language.  It was meant to deal predominantly with additions to the
> language, as can be inferred from numerous parts in the phrasing.  As I
> mentioned in the past - it wasn't even intended to deal with simpler
> deprecations, but it appears that the cat is out of the bag on this one.
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
> of the same bag.  Using the RFC to deprecate fundamental behaviors of the
> language - such as how the language deals with undefined variables - is
> simply off the table.
>
>
>
> You may be wondering, in that case, what processes do we have to deal with
> such changes then?  The answer is simple.  We don't.  We don't have to have
> them either - the fundamental language behaviors are here to stay.
>
> Deprecating the ability to rely on the expected default value of
> uninitialized variables falls squarely in that category.
>
>
>
> Reclassifying a notice to a warning is a possibility - people's code will
> still run, and they'll be able to continue using these behaviors going
> forward as well if they want to (perhaps with minor tweaks to error
> reporting levels).  Turning a notice to an error isn't reclassifying an
> error level.  It's deprecating a behavior - and we're not talking about
> some
> esoteric extension, but a documented, well-defined, fundamental behavior of
> the language for over two decades.  The fact many of you think it's
> horrible
> does not change that.  Deprecating such fundamentals is simply outside of
> the mandate of internals@, regardless of whatever majority appears to
> exist
> in favor of it at a given time.
>
>
>
> Similarly - adding typed variables - is certainly a future option.
> Changing
> PHP to require typed variables (without opting in) - is well outside of the
> internals@ mandate.
>
>
>
> For areas like that - our options are either doing nothing, or providing
> opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
> 2nd option, but there is no 3rd.
>

If you want to have an authoritative say on what the RFC process is for or
not, please start a new RFC about it: your mail is just straight out
inappropriate.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--000000000000faa9e905925c5f4e--