Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119141
MIME-Version: 1.0
References: <CAMXcktOiFH-0f0PG9cKkkVaczjNLSzQzzPUBcoLyn54X=c74og@mail.gmail.com>
In-Reply-To: <CAMXcktOiFH-0f0PG9cKkkVaczjNLSzQzzPUBcoLyn54X=c74og@mail.gmail.com>
Date: Tue, 13 Dec 2022 23:27:25 +0000
Message-ID: <CA+p1FaZ4AXfdKMFHdU420o6B5vBEQ-PUW8gDr5EUTiB9+CmNmw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000c6cda05efbdf77c"
Subject: Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
From: davidgebler@gmail.com (David Gebler)

--0000000000000c6cda05efbdf77c
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 12, 2022 at 10:20 PM Dan Liebner <dliebner@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.

--0000000000000c6cda05efbdf77c--