On Mon, May 2, 2022 at 2:15 PM Guilliam Xavier <guilliam.xav...@gmail.com> wrote:
> On Wed, Mar 16, 2022 at 9:57 AM Christian Schneider > <cschn...@cschneid.com> wrote: > > > > Am 16.03.2022 um 06:52 schrieb Juliette Reinders Folmer < > php-internals_nos...@adviesenzo.nl>: > > > I've just been looking in detail at the Partially Supported Callables > deprecation RFC: > https://wiki.php.net/rfc/deprecate_partially_supported_callables > > > > > > The RFC explicitly excludes the `is_callable()` function and the > `callable` type from throwing deprecation notices. > > > > > > [...] I wonder if the decision [...] is the right one (though I > understand the desire to keep [them] side-effect free). > > > > > > Consider these code samples: > > > > > > function foo(callable $callback) {} > > > foo('static::method'); > > > > > > [...] in PHP 9.0 the function will start throwing a TypeError. > > > > [...] This is a major problem because code which was "just working" > directly goes to a TypeError without a migration phase warning about it. > This is something I've repeatedly advocated against. > > > > > if (is_callable('static::method')) { > > > static::method(); > > > } > > > > > > [...] in PHP 9.0, the behaviour of this code will be silently reversed > for those callbacks which would previously result in `is_callable()` > returning true, which makes this a potentially dangerous change without > deprecation notice. > > > > I agree with you here: Code which silently changes behavior is also a > migration hassle. > > Hi, > > I too would rather have "extra" deprecation notices in 8.2 than > *sudden errors / silent behavior changes* in 9.0 (for the callable > type declaration / the is_callable() function)... > > > The point is that this is not an usual deprecation, something that will change to an error in the future. In the end, it's just a change in behavior with no error before or after. It does not fit the "deprecation". As I dealt with several PHP upgrades, and I'm still going to deal with them in the future, I proposed an idea at some point on the mailing list: To find a way to "flag" a behavior change. The problem is that it should be something outside E_ALL, or to be able to handle it in a totally different way than setting an error handler for it. Something that can be used when preparing for an PHP upgrade, something like: register_version_change_handler(callable $callback, $toPhpVersion) While preparing for a future runtime version, it would be deployed to production and would record behavioral changes in a logging system. These changes need to be manually reviewed, of course, as a change can be to return false instead of null and if that value would be used further in an if. When using in a library maybe there could be some token like @@@ to not trigger the handler. So yeah, this cannot really be an usual deprecation, it needs to be something else, IMO. Regards, Alex
