Re: Revisiting RFC: Engin e Warnings -- Undefined array index
| From: | Derick Rethans | Date: | Mon, 12 Dec 2022 22:52:56 +0000 |
| Subject: | Re: Revisiting RFC: Engin e Warnings -- Undefined array index | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119110@lists.php.net to get a copy of this message | ||
On 12 December 2022 22:20:27 GMT, Dan Liebner <dliebner@gmail.com> wrote:
>It has been proposed to make the error level of "Undefined index"
>configurable so that teams and individual developers can decide for
>themselves how they want this situation to be handled. Given that:
>
> - PHP has been treating this as an E_NOTICE for over 20 years
But not in the last three years.
> - the change is a breaking change affecting many large codebases
> ubiquitously (unless one were to unadvisedly suppress E_WARNING errors)
No, code doesn't break. It now shows a warning instead of an error. There is no behavioural
change.
> - 7.4 is now deprecated
Yes, as each release does 2+1 years. Which also means you've had 3 years to address this in
your code base(s) already.
>I think making the error level of "Undefined index" configurable is a very
>reasonable suggestion, and I support it.
Adding a configuration setting to make this a notice on some installations and not on others, would
just mean that anything that needs to be able to run everywhere needs to take care to not rely on
the setting either way, making it harder to develop portable code.
We're also not generally anything near keen on adding settings that change behaviour , and
suggesting to add one to make a warning a notice seems very far short of a bar that needs to be
reached before many of us would agree to add a setting to make PHP less portable.
Alternatively you can just fix your code.
>Are we able to revisit this topic as a community and potentially bring in
>more PHP developers from around the world to weigh in?
You're always free to follow the RFC process, but I think you'll just up wasting your, and
everybody else's, time with it.
I can't see this being reversed, nor a setting added for, through an RFC process.
cheers
Derick