phpc.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A server for PHP programmers & friends. Join us for discussions on the PHP programming language, frameworks, packages, tools, open source, tech, life, and more.

Administered by:

Server stats:

837
active users

This question is asked partially in frustration, but also partially in genuine curiosity.

What changes in recent 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 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?