On 1-5-2022 9:54, Rowan Tommins wrote:
On 1 May 2022 03:49:11 BST, Juliette Reinders Folmer
<php-internals_nos...@adviesenzo.nl> wrote:
As far as I understand it, if the deprecation notice is **only** thrown for the
deprecated callables, the code can always be adjusted to use the recommended
replacement code patterns as per the RFC to make the code cross-version
compatible with PHP 9.0 (and prevent the deprecation notice).
My point is that returning false is not an error, so there may be code out
there where no adjustment is actually needed, because either the old or new
return value is fine.
As a very unlikely example that demonstrates the principle, imagine someone is
randomly generating strings which look like callables but aren't. They use
is_callable and look for a return value of false to confirm the generated
string is not callable in the current environment. Since new strings are
generated each time, they don't care how the same string will behave in a
different version of PHP, so the deprecation notice is just a nuisance to them.
To repeat, I don't think that exact example is likely, but given the ingenuity
of developers, I was worried there might be some other code pattern that put
developers in that position.
I appreciate your concern.
Maybe this can ease your unease a little: in my investigations I did
come across one (much less sophisticated) example of the kind of pattern
you describe (in a method for Mockery, but with a hard-coded name of a
method which shouldn't exist in a mocked class - the actual code has
since been fixed, but this is what it was prior to the change:
https://github.com/mockery/mockery/blob/472fa8ca4e55483d55ee1e73c963718c4393791d/library/Mockery/Mock.php#L939
- and yes, this code did need changing anyway as otherwise the behaviour
of the method would be reversed in PHP 9.0).
Having said that, that was ONE instance of an `is_callable()` check with
a deliberately not existent method, versus dozens of instances of the
code pattern which triggered this discussion.
