# PHP 8 Backward Incompatible Change Notifications - Thread: https://externals.io/message/120351 - Original archive: https://news-web.php.net/php.internals/120351 - Started by Alan Smithee on 2023-05-18T21:34:28+00:00 - Messages: 2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #120351 — Alan Smithee — 2023-05-18T21:34:28+00:00 URL: https://externals.io/message/120351#120351 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 --- ## #120355 — Thomas Bley — 2023-05-19T03:52:08+00:00 URL: https://externals.io/message/120351#120355 · In reply to: #120351 Hi Alan, regarding "String to Number Comparison", you can cast the value to int to get the old behaviour: php -r "var_dump(0 == (int) '0');" php -r "var_dump(0 == (int) '0.0');" php -r "var_dump(0 == (int) 'foo');" php -r "var_dump(0 == (int) '');" php -r "var_dump(42 == (int) ' 42');" php -r "var_dump(42 == (int) '42foo');" gives: bool(true) bool(true) bool(true) bool(true) bool(true) bool(true) Best Regards Thomas > Alan Smithee hat am 18.05.2023 23:34 CEST geschrieben: > > > 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 > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php