Re: Deprecated partially supported callabl es: should is_callable() t hrowa deprecation notice ?

From: 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]

« previous php.internals (#117568) next »