Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106963
To: "'PHP Internals List'" <internals@lists.php.net>
Date: Thu, 12 Sep 2019 17:44:03 +0300
Message-ID: <076701d56978$86020910$92061b30$@php.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0768_01D56991.AB500460"
thread-index: AdVpdKJV77qMYNHSRqeIC8bFiEITfA==
Content-Language: he
Subject: Changing fundamental language behaviors
From: zeev@php.net ("Zeev Suraski")

------=_NextPart_000_0768_01D56991.AB500460
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.

 

Zeev

 


------=_NextPart_000_0768_01D56991.AB500460--