On Monday, 22 January 2024 at 18:53, Larry Garfield <la...@garfieldtech.com> wrote: > I am in support of this change. My only concern is timeline. This RFC would > deprecate it in 8.4, and presumably support would be removed in 9.0. While we > haven't discussed a timeline for 9.0, historically the pattern is every 5 > years, which would put 9.0 after 8.4, which means only one year of > deprecation notices for this change.
There is no reason as to why 9.0 should come after 8.4, and I fundamentally disagree with the logic that we somehow need to "plan" deprecations around how much time we need to provide users to upgrade. To this day, I have never been provided any evidence that longer deprecation times actually lead to users upgrading their code sooner and not delay the inevitable. We were even told to shunt mass deprecation RFCs for 8.0 to 8.1, effectively reducing how much time users have to upgrade for the sake of simplifying the migration from 7.4 to 8.0. The idea for this RFC was floated around the time of PHP ***7***.4, but this was deemed too soon due to cross version compatibility. Moreover, asking core developers to magically figure out all the various ways PHP is bonkers or broken in a specific narrow time frame, just so userland can have X version where the deprecation exists until removal, is unreasonable. If this is the model that we should seek, then we should *completely* move away from our current versioning system and do something more like Python that provides 2 version where a feature is deprecated before removing support. E.g. features deprecated in Python 3.9 were removed in Python 3.11. As such, I will not entertain this idea of timelines and when it is the "right time" to deprecate something for it to be removed at the "right time". If this is something people feel strongly, an RFC to change what our versioning is and means should be done instead. > Given the massive amount of code that built up between 5.1 and 7.1, and 7.1 > and today, I worry that a year won't be enough time for legacy code to clean > up and it would be another "OMG you broke everything you evil Internals > <expletive deleted>!" like the "undefined is now warning" changes in 8.0. (In > both cases, well-written code any time from the past decade has no issue but > well-written code is seemingly the minority.) I find this comparison disingenuous, fixing undefined variables is one, if not two orders of magnitude harder than fixing this issue. Fixing implicit null to scalar types coercions for internal functions causes way more havoc than this for legacy codebases, and yet we have consistently maintained the rationale for the deprecation. While I do take into consideration the impact RFCs can have on existing code bases, I consider having clear, easy, and comprehensible semantics to be way more important than supporting some complicated and confusing semantics for the sake of BC. There will always be code running on a completely outdated version of PHP due to whatever reason. And refusing to fix the language and its semantics for the vast majority of new code that is going to be written in it feels like a bad decision to me. Especially if fixing it results in engine simplifications. We are our own project, and we need to make choices for the sake of the health of the project, and this means removing stuff in a reasonable timeline. I personally don't work on PHP to do legacy maintenance and keep running it at all cost, if I did want to do this I'd be writing COBOL. I work on PHP because I believe it has a long future ahead of itself, and that new people will learn it and use it. And forcing those people to need to learn, and remember bazillions of gotchas really doesn't sound fair to them IMHO. > The RFC notes that PHPStan and friends have an easy flag to make the change, > which is great, but still that's a minority of PHP devs that even know to use > static analysis. One does not need to use a static analyser to determine or fix this issue, indeed, I didn't even mention static analysers in the RFC as PHP_CS_FIXER is a tool for enforcing coding styles and is capable of fixing this issue. This tool and other code formatting tools are used more widely and for longer than static analysers. Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
