On 29-4-2022 16:36, Rowan Tommins wrote:
On 29/04/2022 03:04, Juliette Reinders Folmer wrote:
And that's basically exactly what I already did which led me to
discover the patterns I posted about as they looked concerning
(though I didn't use Nikic's tool, but the WIP PHPCompatibility
sniff)...
I scanned a significant number of widely-used codebases and their
dependencies and used the PHPCS `--report=code` view to see the code
being flagged in context.
- Some of the things flagged were/are false positives (WIP sniff,
still fine-tuning), which I could dismiss out of hand.
- Some of the things flagged is code which will start throwing
deprecation notices (all good).
- Some code pattern flagged peaked my curiousity as they wouldn't
throw a deprecation notice, but would lead to reversed behaviour...
which is when I posted about this in the channel with the typical
pattern I identified as dangerous without deprecation notice.
Great, that's all I wanted to hear, I'm not sure why it became such an
argument.
Sorry for the confusion, I (mistakenly) thought it was clear from the
start of the thread that I'd done my research.
I just didn't want to be having another conversation in a year's time
with people whose code is raising deprecation notices they can't do
anything about, because we made assumptions about how something's used
without actually looking at it.
I'm not sure I understand what you mean...
As far as I understand it, if the deprecation notice is **only** thrown
for the deprecated callables, the code can always be adjusted to use the
recommended replacement code patterns as per the RFC to make the code
cross-version compatible with PHP 9.0 (and prevent the deprecation notice).
So, `if ( is_callable( 'self::methodName' ) ) {}` could be adjusted to
`if ( is_callable( self::class . '::methodName' ) ) {}`, or in the worst
case if PHP < 5.5 would still need to be supported: `if ( is_callable(
__CLASS__ . '::methodName' ) ) {}`.
No matter whether the code pattern is exotic (and may not have been
considered), making the code cross-version compatible will generally
still be desirable as the expected behaviour would otherwise still be
reversed in PHP 9.0.
