On 11/04/2022 20:22, Craig Francis wrote:
Keep in mind, if you're using `strict_types=1`, great, you're not affected
(I'm not either)... however, I work with quite a few developers, and it's
causing them a lot of problems, and their current approach is to either
disable the deprecation warnings, or to stay with 8.0, simply because they
do not have the time to make the changes... I will note that one team has
been trying to update their code base, it's about 6 months later, and they
still keep adding `strval()` to silence these deprecation warnings (yeah, I
know, not good, but it's the easy solution).

This doesn't only apply to end user developers, but also to library and toolchain developers who need to maintain code covering a range of PHP versions, and who also need to make these trade-offs.

It's those maintainers that have to deal with the impact of this type of change, whether needing to apply changes to their libraries to "suppress" the deprecation notice; or dealing with end-user developers raising the same issues time and again about it because they don't want to see deprecation notices appearing in their logs. Even though this was only a deprecation, most end-user developers don't recognise that difference from logged errors when using libraries, so the impact is felt most heavily by library and toolchain maintainers. This 8.1 deprecation was the one that created the most work, and the most stress for me; and even with an average of 85% code coverage with tests, I'm still not certain that I've resolved every instance using the dirty `$x ?? ''` approach when calling PHP core functions. In many ways, readying code for the 8.1 release because of this deprecation was more painful and time consuming than for the 8.0 release. With all the new deprecations being added for 8.2, I'm looking forward to it even less.

That's also why I wish there was a better risk assessment made for every deprecation RFC; becase all too often there's little or none; and why I get frustrated whenever a question is raised about an RFC, and the person raising these concerns is too often shouted down for raising "a storm in a teacup".

Mark Baker

|.  \     \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|


PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to