Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106977
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net>
In-Reply-To: <076701d56978$86020910$92061b30$@php.net>
Date: Thu, 12 Sep 2019 12:16:35 -0400
Message-ID: <CAKuGYLQA+XMHLGXPM4n_eEdp-d1=WzDE4Z4iLOzhD+4m83McaQ@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000006e23c05925d776d"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: matthewmatthew@gmail.com (Matthew Brown)

--00000000000006e23c05925d776d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Without your contributions in the early 2000s, PHP likely would not enjoy
the popularity it does today.

But I don't think that gives you veto power over the entire process. You
haven't made any significant contributions to the codebase in over a
decade, and yet the language has still gained many more users in that time
frame, with some fairly major backwards-incompatible changes along the way.

I think you have to come to terms with the fact that today you are a single
vote in this process =E2=80=94 though you are, of course, free to write you=
r own
RFCs.

Best wishes,

Matt

On Thu, 12 Sep 2019 at 10:44, Zeev Suraski <zeev@php.net> wrote:

> I was really really hoping that we will avert having to dive into this an=
d
> 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 th=
e
> 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 ou=
t
> 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 wit=
h
> such changes then?  The answer is simple.  We don't.  We don't have to ha=
ve
> 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 t=
he
> 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.
>
>
>
> Zeev
>
>
>
>

--00000000000006e23c05925d776d--