Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117657
Message-ID: <f03eec61-3806-101e-2f39-22cd872d7f64@gmx.net>
Date: Mon, 2 May 2022 14:28:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Content-Language: en-US
To: internals@lists.php.net
References: <62317B01.90907@adviesenzo.nl>
 <3F016525-CCDE-4229-9260-7C76A6FF42E1@cschneid.com>
 <CAC5V6giGcknLfVuSMWhYhPd3gsYrnCcHO_ZiEkjnf24V5R3MuA@mail.gmail.com>
 <CAAwdEzBnpCGTzapSBqusZ-G98D_Nw9xQ7DZpYJ3Kf7dgyhvCzA@mail.gmail.com>
In-Reply-To: <CAAwdEzBnpCGTzapSBqusZ-G98D_Nw9xQ7DZpYJ3Kf7dgyhvCzA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecated partially supported callables: should
 is_callable() throw a deprecation notice ?
From: a.leathley@gmx.net (Andreas Leathley)

On 02.05.22 13:56, Alexandru P=C4=83tr=C4=83nescu wrote:
> 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 t=
hem
> 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 i=
t.
> 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 b=
e
> 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.

To me, adding another error/change handler system seems like a bad way
of dealing with this, not to mention that you need to introduce this
behavior in a PHP version first before anyone can then use it, so it
would be years before this could be useful, and even more years until
there would be established patterns and enough knowledge around it.
Using the existing way of notices, warnings and errors seems just as
good to me, and people have been handling those for many years. Any new
way of dealing with this should have a very high bar to clear and would
need to prove a huge gain in value.

To me this does fit the definition of a deprecation - behavior for the
given code will change intentionally in a future version, and you are
warning about that future change. But one could also emit a notice, or a
warning. The advantage of deprecation notices is that many tools ignore
those specifically, as they are something to look at, but not
necessarily right at this moment. Being more lenient in certain
situations with deprecation notices is therefore a good pattern for
easier adoption of new versions. I have included that behavior in my own
applications, by logging deprecations separately - I will check them out
once in a while, but they do not need immediate attention. Any other PHP
notice or warning would warrant immediate attention, as it would be
unexpected.