Recent searches
Search options
This question is asked partially in frustration, but also partially in genuine curiosity.
What changes in recent #PHP versions have "required complete rewrites"? Really, which?
The most invasive changes I can think of in recent memory are "undefined vars are now E_WARNING" in 8.0, and "internal interfaces now have types" in 8.1. While addressing those can be annoying... they don't require a full redesign.
1/2
I know, because I *did* that update for TYPO3, which is a huge codebase. It didn't force a rewrite. It didn't take years to do. It took me maybe a month or so to fix nearly all PHP 8.0 compat issues. In a 20 year old codebase still built on arrays.
So... really, where is this idea that you're forced to "completely rewrite" code to be PHP 8 compatible coming from? I genuinely don't understand.
2/2
@Crell It's often not a complete rewrite.
It's instead death by a thousand deprecations and small changes.
Example: switching resources to objects. Great idea! I love the type safety! But it introduces subtle bugs in code that was checking for resources and verifying resource types previously. And not all of them have been switched yet!
Or deprecation of dynamic properties. You may not realize you were even using them... and now a warning, which your error handler converts to an exception.
@Crell My point in that is that some of the stuff is really subtle, and may not even be detected in your test suite. That's why folks are reluctant to upgrade, and where the time and effort are spent. It's not a full rewrite, but it's not an _easy_ update, either, particularly if you're not 100% famililar with all the ins and outs of your code, and the libraries you use.
Amen to that.
If the incompatibilities are so subtle that it is not possible to build automated code scanners to identify them, there's gonna be little appetite for product owners to green-light an app upgrade / php version migration, esp. taking into account that a huge amount of applications, unlike libraries, do not even have automated testing in place.
"if it ain't broken don't fix it" is a tough proposition to beat
ps: most of my own packages are currently tested with all php versions from 5.4 to 8.2, so it is definitely doable to have code that can work on all versions.
It does take time to get there though. I'd say most of the time I spent on that was wresting with testing automation rather than with the language itself - but it is still a chore.
@gggeek @Crell Yeah, it's definitely possible. With the number of packages in Laminas/Mezzio... we chose instead to narrow our security window. As it is, we still spend 1/3 or more of each year of total maintainer effort on tasks related to version compatibility.
(The side benefit to narrowing our window, however, is that we're adopting new language features more quickly, which is largely reducing the total code, in both line count and surface area. The new type changes in PHP are a huge boon!)