Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120351
MIME-Version: 1.0
Date: Thu, 18 May 2023 17:34:28 -0400
To: internals@lists.php.net
Reply-To: alan.smithee@fivecolorteam.com
User-Agent: Roundcube Webmail/1.4.3
Message-ID: <cf80f75109e4e0942dd19ce66553556f@fivecolorteam.com>
Organization: Five Color Team
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: PHP 8 Backward Incompatible Change Notifications
From: alan.smithee@fivecolorteam.com (Alan Smithee)

Hi Internals!

Looking for counsel from the PHP maintainers here regarding the upgrade 
path from PHP v7 to v8.

There is a subset of backward incompatible language changes that are 
remarkably tricky to track back into a codebase through manual code 
inspection, automated testing, or static analysis (...I'd love to be 
proven wrong here). The behavior change in these cases are triggered by 
data passed into functions or operators at runtime, such as "String to 
Number Comparison" [1].

Using this example, in a large-enough (and legacy-enough) codebase for a 
data-driven application where there is a cost to every change, I am 
struggling to find an effective mechanism for targeting the set of all 
equality comparisons in the codebase that could potentially operate on a 
pair of number/string operands.

I've found that the most effective mechanism that has helped me to 
quickly and comprehensively identify areas of code at highest risk for 
the upgrade has been deprecation and warning notifications provided by 
the PHP language regarding backward incompatible changes.

To this end, I'm considering patching the current version of the 
language I use, i.e. v7.4.24, for my own benefit and introducing more 
notifications for the handful of highest-risk, backward incompatible 
changes not currently reported by PHP.

I see Nikita Popov has already done something along these lines [2] for 
the "String to Number Comparison" change mentioned above.

My questions for the group:

   1. Are there any particular reason(s) why some PHP 8 backward 
incompatible changes, like "String to Number Comparison", weren't 
instrumented as deprecation or warning notifications in PHP 7?
   2. Are there simpler or more effective strategies to account for the 
set of backward incompatible changes I've called out given the 
constraint of a large, legacy codebase?

[1] 
https://www.php.net/manual/en/migration80.incompatible.php#migration80.incompatible.core.string-number-comparision
[2] https://github.com/php/php-src/pull/3917

Thanks in advance for any insight or advice anyone may be able to offer!

-- 
ALAN SMITHEE
Software Engineer | Five Color Team