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 <alan.smit...@fivecolorteam.com> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
