On Mon, Dec 12, 2022 at 10:20 PM Dan Liebner <dlieb...@gmail.com> wrote:
> As the RFC points out, "Some languages, such as JavaScript, do not consider > accesses to undefined array keys to be an error condition at all, and allow > such an operation to be performed silently." > It is by definition an error condition though. You're trying to access something which doesn't exist. > > For the last 20 years, it's been my impression that PHP also embraced this > philosophy, and that raising an E_NOTICE for "Undefined index" was more or > less offered as a debugging tool, as a matter of practicality. > In the earlier days of PHP, it was more acceptable to allow garbage in scripts. Generally, the community consensus has been that trending away from that has been a positive. It's strongly arguable that E_NOTICE was never appropriate for undefined array index access, since it is not really something which can occur in "the normal course of running a script" (since it necessarily means your script is broken). > > JavaScript returns the undefined primitive for accesses to undefined array > and object keys. PHP returns the NULL primitive respectively despite > raising an error. > > Here's my biggest criticism: the change essentially forces this: > $arr['key'] > > to be rewritten as this (or some other intolerably bad alternative): > isset($arr) && isset($arr['key']) && $arr['key'] > > This is a major regression in my opinion as far as productivity and > readability are concerned. > It seems strange to quibble about readability and syntax when you're talking about a situation in your code which is by definition an error condition. Accessing something which doesn't exist isn't the same as accessing something which does exist and it not having a value (i.e. the value is a null). Null = "Can I have the address for this customer please?", "No sorry, we don't have an address on file for them. "Undefined = "Can I have the gooble-gabble for this customer please?", "The what?" But sure, we don't always have a guarantee about the structure of some data, especially in web where input usually comes from an HTTP request which may or may not contain anything. But in those situations we can check instead of making assumptions. Good = "Hey, just checking, do we have something called gooble-gabble on file for this customer?", "Sure, here it is" for one customer, "No, sorry that's not a thing" for another (this is your array_key_exists / isset / null coalesce / whatever) Bad = "Can I have the gooble-gabble for this customer please?", "Sure, here it is" for one customer, "The what?" for another > > 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. There's a much better way of allowing developers to decide for themselves how to handle the gooble-gabble situation in a future major release; have undefined index access throw an UndefinedIndexError which can be caught. Then we can say "Can I have the gooble-gabble for this customer please? And if gooble-gabble isn't a thing, no problem, I can deal with that" That's my two cents, cheers.
