Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117669
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>
 <44517fe1-21da-41ce-0c9d-d69c2b4bf6f9@gmail.com>
Message-ID: <62736292.2000506@adviesenzo.nl>
Date: Thu, 5 May 2022 07:37:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <44517fe1-21da-41ce-0c9d-d69c2b4bf6f9@gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080904050905040907070801"
Subject: Re: ***SPAM*** Re: [PHP-DEV] Deprecated partially supported
 callables: should is_callable() throw a deprecation notice ?
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------080904050905040907070801
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2-5-2022 14:43, Rowan Tommins wrote:
> On 02/05/2022 12:56, Alexandru Pătrănescu 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".
>
>
> That was my instinct too, but Juliette's analysis elsewhere on the 
> thread has convinced me that it is very likely that anyone seeing this 
> deprecation would want to change their code, rather than allowing it 
> to change behaviour in 9.0.
>
> Perhaps a reasonable comparison is the change in precedence of the 
> concatenation operator 
> [https://wiki.php.net/rfc/concatenation_precedence]. The expression 
> ("sum: " . $a + $b) is valid in PHP 7 and PHP 8, but has different 
> results; PHP 7.4 included a deprecation notice because users would 
> almost certainly want to choose which behaviour they wanted.
>
> The difference in this case is that the code change probably won't 
> happen in the same place as the is_callable() function call, but 
> somewhere further up the stack. For instance, a framework function 
> might accept arbitrary values and test them with is_callable; an 
> application using that framework might pass "parent::foo", which will 
> change behaviour in 9.0. It is the application's author who will 
> benefit from the deprecation notice, so they can pass a different 
> value whose behaviour isn't going to change.
>

I was going to mention the same example as the precedent ;-)

Either way, how will this get picked up now ? What are the next steps to 
put this thing in motion ?

(Note: please don't suggest for me to create a PR - I'm a PHP dev, not a 
C-dev)



--------------080904050905040907070801--