On Sat, 2022-01-22 at 01:58 -0600, Trevor Cordes wrote:
On 2022-01-19 Gilbert E. Detillieux wrote:
I'd hold off on making/maintaining your own fork until such a time the PHP brain-trust actually raises things from a warning to an error. In the meantime, if you're logging using rsyslog, it would be fairly easy to add a one-line filter rule to eliminate the needlessly-noisy warning messages. No more full logs, and no more actual serious warnings getting lost like a needle in the haystack!
We're kind of lucky in this case because I noticed these things a while back reading PHP 8.x changelogs, and have been writing about the craziness in the newsletter for a couple of years. (However, I didn't believe some of the more insane plans.) How many would know about this if not for MUUG (assuming it's someone who remotely cares)? Although, not like being aware has helped at all. Like Adam said, it's like systemd, it shows up and is shoved down your throat, leaving many people with a bad taste.
For what it's worth this change has been a very long time in coming, and the stewards of PHP couldn't even agree to rip off the band-aid when the proposal was made for PHP 8.0.
E_ALL has been the "recommended" and later "development" (non-default) error reporting level going all the way back to PHP 4.1 in December of 2001. Later E_ALL & ~E_DEPRECATED (with ~E_STRICT added while it existed) was made the "production" (default) error reporting level in PHP 5.3 in June of 2009.
In other words, unless you haven't touched your PHP configuration in over a decade, you should already have been aware silencing notices is not the norm. If you've published a library to PEAR or Packagist in the last thirteen years, you've either already made the change, or have been inconveniencing people using default PHP configurations for a very long time.
Far from being "insane", the current state of affairs is a very gentle and gradual move away from something which (whether you agree or not) has been considered bad practice by those guiding the evolution of the language for over twenty years
Personally, I'd have preferred if the E_NOTICE category had been retired rather than E_STRICT https://wiki.php.net/rfc/reclassify_e_strict, with then-current language-use E_NOTICE events converted to E_STRICT. How a notice materially differs from a warning is pretty nebulous, but a "STRICT" category is at least obvious in meaning, if not necessarily in severity.