Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112614
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Wed, 23 Dec 2020 13:19:01 -0600
Message-ID: <71324EDF-EDB5-4E41-8BBB-ED08A0E1D262@joshbruce.dev>
References: <DM6PR07MB6618A715D71632194527E01EF9DE0@DM6PR07MB6618.namprd07.prod.outlook.com>
Cc: Ben Ramsey <ben@benramsey.com>, Mike Schinkel <mike@newclarity.net>,
 internals@lists.php.net
In-Reply-To: <DM6PR07MB6618A715D71632194527E01EF9DE0@DM6PR07MB6618.namprd07.prod.outlook.com>
To: tyson andre <tysonandre775@hotmail.com>
Subject: Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays
From: josh@joshbruce.dev (Josh Bruce)


>=20
>> I actually like the idea of flags added to `is_array()` for this.
>>=20
>> Something like:
>>=20
>>     is_array($value, ZERO_INDEXED | ASSOCIATIVE | INTEGER_INDEXED)
>>=20
>> I=E2=80=99m not suggesting these names; they=E2=80=99re for illustration o=
nly.
>=20
> I'm strongly opposed to adding any flags to is_array - keeping basic type c=
hecks simple would help in learning/reading/remembering the language,
> has a small impact on performance for calls that aren't unambiguously qual=
ified (especially if using both), and it makes it harder to see issues like
> `is_array(really_long_multiline_call(arg1, arg2, ZERO_INDEXED))`

tl;dr: How often do we find ourselves needing to check if an array uses orde=
red integer keys?? Compared to just forcing the passing through array_values=
?? For my implementation it=E2=80=99s only there because I=E2=80=99m experim=
enting with separating the three main types (for me): PHP unordered mixed ke=
ys, string-only-unordered-keys, and int-only-ordered-base-0-keys.

Under most circumstances I would strongly agree. With that said, I think req=
uiring a certain arrangement of keys is a rare case; presumption being a sol=
ution would be in place if it wasn=E2=80=99t. Further, I think there are qui=
te a few options to manipulate keys and we have 20+ years of linguistic bagg=
age.=20

Thought exercise I=E2=80=99m going through that would let userland opt-in to=
 the complexity of further restricting the type-checkable PHP array with pos=
sible flags (just to continue the exercise):

1. PHP_STD_ARRAY: unordered map with keys that are strings, integers, or bot=
h - default...no BC, no additional learning curve except when users want to b=
e more specific; all systems normal.
2. STRING_KEYS: all the keys are strings.
3. INT_KEYS: all the strings are integers.
4. ORDERED_ASC: keys are ordered from least to greatest (string or int).
5. ORDERED_DESC: keys are ordered from greatest to least.
4. INT_KEYS_BASE_ZERO: the first key is 0 (??)

I might be missing some cases, but this would cover current PHP array; the a=
bility for users to sort on keys, not values; and wouldn=E2=80=99t require a=
dditional function or named thing as PHP =E2=80=9Carray=E2=80=9D can be any o=
f those things and it=E2=80=99s more a matter of whether users want to be mo=
re restrictive and why.

My use case for wanting this is pretty much to be more opinionated in my lib=
rary and make a hard distinction between a base-0-int-ordered-array and an s=
tring-unordered-array. My PHP-like variant is actually call List, funny enou=
gh - with the ability to make it an array (array_values) or a dictionary (pr=
epending int indexes with a letter to address dynamic casting).=20

And, again, I=E2=80=99ve never had to run a check really - because if I need=
 a =E2=80=9Cpure array=E2=80=9D - I run array_values.

I=E2=80=99m cautious about introducing a new name against a known type as ab=
stract as PHP array - which can be just about any combination of key-value p=
air constructs.=20

If introducing a new name, I would hope to introduce a new type as well - ev=
en if under the hood it=E2=80=99s using checks against the more generic PHP a=
rray.

function hello(list $my_list_maybe)

The hope isn=E2=80=99t that the flags become a permanent fixture but allow b=
etter visibility into what userland wants from arrays without adding to the S=
L and without users needing to change their current mental models - do a lot=
 of us *want* to have this ability (verify the metadata on keys of an array)=
?? Or is it just a fringe group of pedantic experimenters like me?? :)

Cheers,
Josh=20=