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 — though you are, of course, free to write your own RFCs. Best wishes, Matt On Thu, 12 Sep 2019 at 10:44, Zeev Suraski <z...@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. > > > > Zeev > > > >
