Re: [Discussion] Expand deprecation notice scope for partially supported callables

From: Date: Thu, 12 May 2022 22:17:04 +0000
Subject: Re: [Discussion] Expand deprecation notice scope for partially supported callables
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-117725@lists.php.net to get a copy of this message
On 12-5-2022 23:30, Claude Pache wrote:
Le 12 mai 2022 à 23:11, Larry Garfield <larry@garfieldtech.com> a écrit : For the callable type declaration, I'm not opposed but is it redundant with the existing deprecation? When would you pass a callable to something and not end up calling it anyway, which would trigger the existing deprecation? (Meaning in practice you'd always get 2 deprecations, which are not necessarily better than one.)
Although such a callable is probably intended to be called at some point, it is not necessarily called immediately, and it may be easier to track the source of it when you trigger the deprecation earlier. Example:
public function registerErrorHandler(callable $onerror) {
     $this->onError[] = $onerror;
}
(Of course, this argument also holds for is_callable().) —Claude
Exactly as Claude says and to quote the RFC:
While it will be common to use the partially supported callable in a callback function call within the function with the type declaration, this may not always be the case, especially in frameworks where callbacks can be registered to be executed later in a limited set of circumstances and those circumstances may not be met by default.
Without a deprecation notice, those “/limited circumstances callbacks/” may not be discovered as needing updating in time for PHP 9.0.
Ref: https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices#adding_a_deprecation_notice_for_callable Smile, Juliette

« previous php.internals (#117725) next »