Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117123
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>
In-Reply-To: <CADyq6sL+BxkwybsaThWbJ=wF+hYM68PepDA54BVje4FLOvyB8Q@mail.gmail.com>
Date: Wed, 23 Feb 2022 16:29:55 +0100
Message-ID: <CAOWwgpnWE6UQ0XAYwKavR6E188NirwJ4_3BEpst2OLCjdEGB_Q@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Mark Randall <marandall@php.net>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e813f705d8b12368"
Subject: Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000e813f705d8b12368
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 22 f=C3=A9vr. 2022 =C3=A0 14:56, Marco Pivetta <ocramius@gmail.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 before 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 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.

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.)

Nicolas

>

--000000000000e813f705d8b12368--