Re: [RFC] Undefined Variable Error Promotion
| From: | Marco Pivetta | Date: | Wed, 23 Feb 2022 18:14:26 +0000 |
| Subject: | Re: [RFC] Undefined Variable Error Promotion | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117126@lists.php.net to get a copy of this message | ||
Yeah, please don't: yet another side effect, deep in some
vendor cruft.
Just stop it, please: I almost have PTSD from 8.1.
On Wed, 23 Feb 2022, 19:02 Nicolas Grekas, <nicolas.grekas+php@gmail.com>
wrote:
> Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker <cmbecker69@gmx.de> a
> écrit :
>
> > On 23.02.2022 at 16:29, Nicolas Grekas wrote:
> >
> > > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta <ocramius@gmail.com> a
> > écrit :
> > >
> > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas <
> > >> nicolas.grekas+php@gmail.com> wrote:
> > >>
> > >>> But this makes me think: we should trigger a deprecation just before
> > all
> > >>> corresponding warnings!
> > >>
> > >> Please, no more deprecation warnings, make it stop 😥
> > >> Yes, undefined variables are a problem, but I just spent 6 months in
> > >> vendor/ code for 8.0->8.1 stuff, and it
> > >> doesn't bring anything but
> > >> frustration: this stuff is statically introspectible, and even more
> > >> side-effects are just more trouble.
> > >
> > > I'm not going to be affected by this RFC at all, and neither are you,
> > since
> > > we use throwing error handlers. But ppl that do rely on code bases that
> > > have undefined vars "by design" will be. I would bet that the number of
> > ppl
> > > in that affected group and that also use a static analyser is very very
> > > small. This means that static analysers are not a pragmatic solution
> > here.
> >
> > That.
> >
> > > Ppl that don't use static analysers deserve a prior notice. There is a
> > > dedicated reporting mechanism in place and we should use it IMHO. With
> > new
> > > deprecations added to PHP 8.1, the ecosystem realized that the tooling
> > > needed to improve - and it did (phpunit, Laravel, etc.). We can and
> > should
> > > add new runtime deprecations when planning a BC break.
> > >
> > > Please consider adding this deprecation Mark (and others.)
> >
> > Do you mean E_DEPRECATED in addition to E_WARNING, or instead? I
> > wouldn't be happy either way.
> >
>
> I mean in addition yes, deprecation before warning.
>
> I considered grouping them as E_DEPRECATED|E_WARNING but that'd break many
> userland error handlers I fear.
>