On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
>
>
> On 25 June 2024 21:24:32 BST, Rob Landers <[email protected]> wrote:
> >The only way you’d observe this (that I can think of) is by performing a for-each loop
> >over the array.
>
> There are many ways you can observe the difference between an absent key and a null value; here
> are just a handful off the top of my head:
>
> - array_key_exists() (that's literally its purpose!)
> - array_keys()
> - count() (if the array held "an infinite number of nulls", we should return infinity
> for every array!)
> - json_encode()
> - print_r(), var_dump(), var_export()
> - extract()
>
> It may be questionable to give meaning to the difference in some of these cases, but different
> it definitely is.
True, but I was mainly referring to what you would do after performing an 'is', in which
case, you probably wouldn't be using any of those functions, or if you needed to, then why do
you need 'is'? Even with the
$hasFoo = $arr is [?'foo' => string];
You still have to run array_key_exists() to determine whether the key exists, which means you likely
still need to figure out a default value, and null-coalesce is perfect for that ... but then it just
points out that it isn't that useful of a check, and that it is inconsistent with itself.
If you are running array_keys(), then why bother performing an 'is' when you should
already know the structure—that's the entire point of it. If you are running a count(), this
kind of goes back to the same thing, but I would think count() would be run on a collection of data
rather than structured data.
For json_encode, I could see something like this being a "final check" of some sort, but
most people are likely json_encoding objects these days.. This might be a good use case for this
syntax, but I feel like this is the wrong way to solve the problem.
print_r, var_dump, etc. are more or less debugging tools. At least, I've never seen their
output used for program execution. I could be wrong.
extract() can go get crushed by an RFC :) but it does occasionally have its usefulness. Even then,
until PHP 9, an undefined variable will still be null.
>
>
> > If we don't like it, we can always create an RFC to treat non-existent keys as an
> > error instead of a warning.
>
> I believe that is the explicit intention or desire of those who raised it from Notice to
> Warning. It would certainly prevent some bugs where a typo leads to the wrong key being accessed.
>
> Personally, I'd like to see a few use cases catered for first, like $counters[$key]++ and
> $groups[$key][] = $value; Perhaps by introducing some equivalent of Python's
> "defaultdict". Because I do agree that the current behaviour is useful sometimes (even if
> I disagree in how to describe it).
I think arrays have their uses, but I'd rather see some purpose-built data structures where you
can fully take advantage of their performance properties—things like linked lists, heaps, etc.
Yeah, there's SPL, but its interfaces are kind of a mess since you can use a queue like a deque
or a stack (which is just weird and might or might not have performance implications), for example.
>
>
> Regards,
> Rowan Tommins
> [IMSoP]
>
— Rob