Workaround for compatibility with PHP 8.6+

[mbeccati]

Usage of is as a class name is deprecated.

See php/php-src#23990

[andypost]

Looks it should be $original & ~E_DEPRECATED

[andypost]

and how it will work with --classmap-authoritative

[mbeccati]

Good point, the workaround is not compatible with --classmap-authoritative

[mbeccati]

I've also unsuccessfully tried a few variants.

[andypost]

@mbeccati for Drupal this patch approach works... at least all tests finally passed

[GrahamCampbell]

Either PHP will revert this, or I will rename the class (aka add a new class and deprecate this one).

[GrahamCampbell]

Trying to work around this is wrong IMO. If people were supposed to do this, then why is PHP even bothering with depreciations at all.

[mbeccati]

As a RM, I'm afraid I don't have the power to revert this change.

It has been voted upon and "is" is going to be a reserved keyword in the pattern matching RFC, which is likely to pass in future. A depracation phase is in order to give time to adjust, by not raising a fatal error.

I was just trying to help with a workaround that would allow a potential 3.0.3 to be compatible with 8.6 without any deprecation being raised.

[GrahamCampbell]

That's OK I don't expect it to be reverted. I would still question what the point of raising deprecations in the engine is if it is expected that userland works around them.

[mbeccati]

Well, a deprecation warns the user that something is going to change, giving them time to adjust before becoming a fatal error in a future version.

[GrahamCampbell]

Then why are we working around it in any way other than not using that class name? ;)

[mbeccati]

@GrahamCampbell the workaround was excusively to add 8.6 compatibility to the current version(s). Renaming the class would be left for a next major update.

[GrahamCampbell]

But it is already compatible? A deprecation is not an incompatibility. Only the actual disallowing of the class by the engine is an incompatibility. If people treat deprecations as incompatibilities, then there is no point in deprecations.

[mbeccati]

If the deprecation is in a project I manage, I can deal with it if I want to. If the deprecation is triggered by a library my project uses, it in an annoyance as I can't do anything about it. Some would probably also report it in a GH issue.

Of course, as the project maintainer you can certainly decide not to do anything about it. Otherwise planning a release that adds a workaround could be a nice gesture to the users. Your call indeed. I think I've spent more than enough on this already ;-)