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!)
@mwop The resource removal was more about engine simplicity; that part of the engine is totally gross and needs to be fixed. But given that, what would have been a "more friendly" way of doing that conversion? (Serious question.)
@Crell For is_resource and get_resource_type to have continued to work on these objects just as they had before.
The way you'd check before was a combination of the two; that breaks completely now. You end up requiring a change in your code to correctly identify resources you're interested in, and those changes are specific to the PHP version in which they were introduced and up, meaning stepped migrations require you to also check the PHP version as part of the conditional.
@mwop How long would it be reasonable to keep such a hack in place? Having is_resource() also means was_resource()?
@Crell Depends on the context.
For a library, you have to keep it in place until your minimum supported PHP version matches where the resource class was introduced.
For an application, it depends on your migration strategy. Some will just jump to the new version; others will do stepped migrations, where code needs to run on both PHP versions before they can switch off the old version.
@mwop I mean for PHP Internals. if is_resource() got a hard coded hack to still return true for a BZip2 object (or whatever), starting in PHP 8.0, what's a reasonable timeframe before that hack gets removed and starts returning false?
@Crell next major.
@mwop @Crell "Identifying resources" sounds suspicious to begin with, to be honest. Do you really have code that returns PHP's numeric resource identifiers and expects the caller to keep track of what they represent? I have never seen this. Almost all is_ressource() I have ever seen can easily be replaced with !== false.
This was in library code, but I've done it in my own code as well.
Since we couldn't previously typehint on resources, we'd test (a) to see if we had actually received a resource, and (b) that it was a resource of the correct type (get_resource_type() === '...' or strstr or preg_match operations). The latter doesn't work with the new resource classes.
