Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117126
MIME-Version: 1.0
References: <620eda0f.1c69fb81.d2cb1.0846SMTPIN_ADDED_MISSING@mx.google.com>
 <5efecaef-a024-3c61-e12e-ffc342956718@gmail.com> <CAOWwgpkcnaVctXu8LgYpp_CLzx0QySbV87ibRqy0aD6qqHmsxA@mail.gmail.com>
 <6214c40e.1c69fb81.73261.05d3SMTPIN_ADDED_MISSING@mx.google.com>
 <CAOWwgpkoGvonQDwOS331JNWLT=zJ8pNN+CEoEce4rtebMn2+0w@mail.gmail.com>
 <CADyq6sL+BxkwybsaThWbJ=wF+hYM68PepDA54BVje4FLOvyB8Q@mail.gmail.com>
 <CAOWwgpnWE6UQ0XAYwKavR6E188NirwJ4_3BEpst2OLCjdEGB_Q@mail.gmail.com>
 <0ce34a07-3ad7-7158-d914-c18f3720ff9d@gmx.de> <CAOWwgpkQ0x2Mpn00PTUBVysLMwc5FcXbAVfcT_i-p7HbGF+CuQ@mail.gmail.com>
In-Reply-To: <CAOWwgpkQ0x2Mpn00PTUBVysLMwc5FcXbAVfcT_i-p7HbGF+CuQ@mail.gmail.com>
Date: Wed, 23 Feb 2022 19:14:26 +0100
Message-ID: <CADyq6sKz2YgeTTwaNRcSjN4WZAuaMdaCOBf1yqXH03=jp6i2LA@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004f87be05d8b3700d"
Subject: Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
From: ocramius@gmail.com (Marco Pivetta)

--0000000000004f87be05d8b3700d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=A9vr. 2022 =C3=A0 17:59, Christoph M. Becker <cmbecker69@=
gmx.de> a
> =C3=A9crit :
>
> > On 23.02.2022 at 16:29, Nicolas Grekas wrote:
> >
> > > Le mar. 22 f=C3=A9vr. 2022 =C3=A0 14:56, Marco Pivetta <ocramius@gmai=
l.com> a
> > =C3=A9crit :
> > >
> > >> 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 befor=
e
> > all
> > >>> corresponding warnings!
> > >>
> > >> Please, no more deprecation warnings, make it stop =F0=9F=98=A5
> > >> 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 th=
at
> > > 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 ve=
ry
> > > 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. Wit=
h
> > new
> > > deprecations added to PHP 8.1, the ecosystem realized that the toolin=
g
> > > 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 man=
y
> userland error handlers I fear.
>

--0000000000004f87be05d8b3700d--