[RndTbl] PHP undefined vars / array indices

[J. King]

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.

-- 
J. King <jking at jkingweb.ca>