I fully understand your point, having more tests is the best thing to do. Unfortunately many old code bases are not written to be tested easily. There is excessive inheritence, traits, reflection, globals, static calls, missing DI, magic functions, feature flags, database dependancies (e.g. 1 request reads 40 tables with 500 queries), library/framework dependancies (some unsupported, unmaintained, deprecated, etc.). So people spend a few months to get the coverage from 10 percent to 20 or 30 percent and the problems are still the same. My point is that every hour being spend on old code is one hour less that can be spend on writing newer code, being better tested, following newer standards, etc. So having language levels would make things a lot easier. There are many more things that should be deprecated and removed, but cannot be done now due to BC breaks and the risks for negative votings on the rfcs. With language levels like <?php8, <?php9, old and new code can be executed together without making bigger changes to the old code. But I also understand the amount of work and increased complexity this would bring to the core development.
Regards Thomas > Pierre Joye <pierre....@gmail.com> hat am 10.04.2023 18:17 CEST geschrieben: > > > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <stephan.sol...@helionweb.de> > wrote: > > > Hello, > > > > I'm sorry if this isn't the correct mailing list for that discussion but I > > couldn't find a more appropriate one where people actually know how the > > wind is > > blowing. > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > deprecations and fatal errors spooked me a bit (details below if you're > > interested). That got me wondering about the long-term stability of PHP > > (as in > > language and API breaks) and I looked at the RFCs. I got the impression > > that > > static typing has a lot of traction now and I have no idea of what the > > fallout > > might be of changing a dynamically typed language into a statically > > typed one. > > > I keep reading this in multiple languages, pr even more frameworks. > > I understand agency work, managers pushing new features instead of a > cleaning some legacy. > > however years of ignoring deprecation notices (very few were introduced > right before 8.0). > > Most of them could have been fixed within a couple of hours in any code > base, if they had tests. > > I would suggest, very very nicely, to review and rethink the development > flows of these projects instead of asking php to freeze. > > best, > Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
