Re: [VOTE] Undefined Variable Error Promotion
| From: | Christian Schneider | Date: | Wed, 16 Mar 2022 09:17:48 +0000 |
| Subject: | Re: [VOTE] Undefined Variable Error Promotion | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117346@lists.php.net to get a copy of this message | ||
Am 16.03.2022 um 10:00 schrieb Mark Randall <marandall@php.net>:
> On 15/03/2022 23:02, Patrick ALLAERT wrote:
>> I am not against the fact this warning becomes an error per se. I am just
>> not very fan of cherry-picking an individual kind of problem (read:
>> notice/warning/error/...) and changing it without a more global frame.
>
> I think we should try to hit all of them, ideally in time for PHP 9.
>
> That was the premise behind:
> https://externals.io/message/116918
>
> It will likely take several RFCs until we've got it in the state we want it, some of those
> are more contentious than others (such as undefined array indexes).
>
> I think undefined property access should throw too, and will likely have supermajority support,
> but let's do it in a separate RFC.
>
> What I don't think we want is the entire package being blocked because a particular item
> (i.e. array keys) is contentious.
This is actually exactly what Patrick is complaining about: No global plan.
I know I'm on the "losing" side of this discussion but sometimes it feels like one of
the main arguments is "we already changed this and that to exceptions, now we have to do it in
this case too". Which, to me, fits the first paragraph of https://en.wikipedia.org/wiki/Salami_slicing_tactics
Maybe we should ask ourselves the question: Why would the entire package be blocked? Just because it
is too big or maybe there *are* subtleties which have not been properly resolved?
- Chris