Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117518
Message-ID: <00eeb55f-50c0-a724-efdd-c4426749c770@demon-angel.eu>
Date: Mon, 11 Apr 2022 20:56:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Reply-To: mark@demon-angel.eu
To: internals@lists.php.net
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com>
 <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
In-Reply-To: <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: mark@demon-angel.eu (Mark Baker)

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|

  I LOVE PHP