Re: Future stability of PHP?

Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g. https://3v4l.org/VfAr4 has 4 different outputs between php 7.x and 8.x. From userland perspective, having <?php8 or <?php9 would make things a lot easier and more productive. Regards Thomas > Craig Francis <craig@craigfrancis.co.uk> hat am 10.04.2023 14:58 CEST geschrieben: > > > On 9 Apr 2023, at 23:10, Kamil Tekiela <tekiela246@gmail.com> wrote: > > I wonder about this every time I hear this claim. What exactly changed in PHP 8.0 that > > made the upgrade path so difficult? The upgrade to PHP 9 may be a little more difficult because of > > some of the recent deprecations, but that's still years ahead of us. > > > > Most of the deprecations and changes do make sense, and while deprecating dynamic properties is > going to be a pain, I think it's going to be worth it (like undefined variables), same with ${} > string interpolation (better to be consistent); and I know it's been mentioned in this thread, > but utf8_decode does get misused a lot (read the RFC as to why). > > But I do not understand "Passing null to parameter # of type string is deprecated" > specifically. > > I should note that the other coercion/type tweaks that G.B.P (Girgias) is suggesting, and has > partially implemented, do make sense: > > https://github.com/Girgias/unify-typing-modes-rfc > > And (fortunately) NULL coercion still works when concatenating NULL to a string, adding NULL to > an integer, NULL being treated as false, etc. > > One team of developers I know are still finding these issues well over a year later (they also > introduce new code that trips it as well); two other teams specifically ignore this deprecation (far > too many instances to "fix"), and one team is still to decide what they are going to do > (annoyingly they are still using 7.4). > > Even Rector gives up and uses (string) $var for every variable > that's a non-nullable string, which can result in thousands of changes in a project > (that's for the ~434 function arguments being checked; personally I'd have only gone with > 335 of the ~997): > > > https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php > > Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't using strict > types, that's going to cause lots of random and unexpected problems. > > Craig > > > > PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it would have been > voted down, and then used to justify the type error): > > https://wiki.php.net/rfc/null_coercion_consistency