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:
- 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? - 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
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.smithee@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:
- 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?- 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/3917Thanks 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