Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117656
MIME-Version: 1.0
References: <62317B01.90907@adviesenzo.nl> <3F016525-CCDE-4229-9260-7C76A6FF42E1@cschneid.com>
 <CAC5V6giGcknLfVuSMWhYhPd3gsYrnCcHO_ZiEkjnf24V5R3MuA@mail.gmail.com>
In-Reply-To: <CAC5V6giGcknLfVuSMWhYhPd3gsYrnCcHO_ZiEkjnf24V5R3MuA@mail.gmail.com>
Date: Mon, 2 May 2022 14:56:42 +0300
Message-ID: <CAAwdEzBnpCGTzapSBqusZ-G98D_Nw9xQ7DZpYJ3Kf7dgyhvCzA@mail.gmail.com>
To: Guilliam Xavier <guilliam.xavier@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eb98a105de061648"
Subject: Re: [PHP-DEV] Deprecated partially supported callables: should
 is_callable() throw a deprecation notice ?
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000eb98a105de061648
Content-Type: text/plain; charset="UTF-8"

On Mon, May 2, 2022 at 2:15 PM Guilliam Xavier <guilliam.xavier@gmail.com>
wrote:

> On Wed, Mar 16, 2022 at 9:57 AM Christian Schneider
> <cschneid@cschneid.com> wrote:
> >
> > Am 16.03.2022 um 06:52 schrieb Juliette Reinders Folmer <
> php-internals_nospam@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

--000000000000eb98a105de061648--