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.
@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 @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.