Re: Deprecated partially supported callabl es: should is_callable() t hrowa deprecation notice ?
| From: | Rowan Tommins | Date: | Fri, 22 Apr 2022 06:47:50 +0000 |
| Subject: | Re: Deprecated partially supported callabl es: should is_callable() t hrowa deprecation notice ? | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117568@lists.php.net to get a copy of this message | ||
On 22 April 2022 02:02:58 BST, php-internals_nospam@adviesenzo.nl wrote:
>I agree it would be a good idea to run a package analysis, but to be fair, in all honesty that
>should have been done for the original RFC, which was completely missing an impact analysis.
That's a fair point, but of course "somebody else should have done it already"
isn't a good excuse not to do it now.
>3. As for the pattern being common or not - the fact that I found it so easily in multiple
>random projects which I elected to test the sniff against, makes me believe the pattern is not
>_uncommon_.
Since there has been some misunderstanding, the usage I think we need to look for is where a
deprecation notice would *not* be useful. In other words, are there people using is_callable in
such a way that even if a value like "parent::foo" changes from returning "true"
to "false", there won't be anything that needs changing, because the code is equally
"happy" with both return values?
I freely admit that I can't think of any such usage off the top of my head, but I wouldn't
have thought of some of the examples already raised either.
If an actual search fails to find such usages, or provides evidence that it is very rare, then I am
absolutely in favour of adding a deprecation notice.
Regards,
--
Rowan Tommins
[IMSoP]