On 2024-06-26 09:58, Rob Landers wrote:
On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
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.
So the issue has nothing to do with this hypothetical infinity of
unobservable nulls, and comes entirely down to the fact that with this
pattern a variable may pass
a) because it does not have a key named 'foo', or
b) because it has a key named 'foo' with a string value.
In other words, "this key is optional, but if it is defined it must
match this pattern".
On its lonesome, that doesn't look very useful, but I expect it would be
one component of a larger pattern (such as "['bar' => string, ?'foo' =>
string, ...]"). Rather than (near-)duplicate blocks for "it does not
have the key" and "it has the key and it holds a string", there can be
one block (which might or might not care about the distinction).
