Re: Changing fundamental language behaviors

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/