Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112586
Message-ID: <42C458F8-739D-448A-BF35-6BAF0C1C24FC@benramsey.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_F6A222E6-ECA7-4E81-91CD-C82F4A5325DE";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Mon, 21 Dec 2020 20:02:18 -0600
In-Reply-To: <EDB9F10F-440A-4EFB-925B-6F1AF7CB8059@newclarity.net>
Cc: tyson andre <tysonandre775@hotmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
To: Mike Schinkel <mike@newclarity.net>
References: <DM6PR07MB6618468A8C4A49818C4E2EB0F9C10@DM6PR07MB6618.namprd07.prod.outlook.com>
 <94748D59-630B-4EE2-8106-B68AA4E449D2@benramsey.com>
 <EDB9F10F-440A-4EFB-925B-6F1AF7CB8059@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for
 list-like arrays
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_F6A222E6-ECA7-4E81-91CD-C82F4A5325DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Dec 21, 2020, at 16:15, Mike Schinkel <mike@newclarity.net> wrote:
>=20
>> On Dec 20, 2020, at 9:09 PM, Ben Ramsey <ben@benramsey.com> wrote:
>>=20
>>> On Dec 19, 2020, at 19:43, tyson andre <tysonandre775@hotmail.com>
>>> wrote:
>>>=20
>>> It can be useful to verify that the assumption that array keys are
>>> consecutive integers is correct, both for data that is being passed
>>> into a module or for validating data before returning it from a
>>> module. However, because it's currently inconvenient to do that, =
this
>>> has rarely been done in my experience.
>>=20
>> I think there are some places where `is_list()` could be unintuitive =
to
>> those who don=E2=80=99t understand some of the idiosyncrasies of PHP.
>>=20
>> For example, with
>>=20
>>    $a =3D ['foo', 'bar', 'baz=E2=80=99];
>>=20
>> `is_list()` will return `true`, but if you run `$a` through =
`asort()`,
>> `is_list()` will return `false` because the keys are no longer
>> consecutive integers, but is there any doubt this is still a list?
>> Maybe in a pure sense, it=E2=80=99s not, but I think this could be =
confusing.
>>=20
>> But now, if we do
>>=20
>>    $b =3D array_merge($a, ['qux', 'quux']);
>>=20
>> `$b` is now back to being a list, so `is_list($b)` returns `true`.
>>=20
>> While I understand the convenience `is_list()` provides--I myself =
have
>> implemented the opposite of this numerous times (e.g.,
>> `is_dict()`)--it comes close to implying a data type that PHP =
doesn=E2=80=99t
>> have, and I think this could give a false sense of type-safety-ness
>> when using this function to check whether something is a 0-indexed
>> array.
>>=20
>> Cheers,
>> Ben
>>=20
>=20
> Would either is_zero_based() or is_zero_indexed() be a reasonable
> name instead?
>=20
> -Mike
>=20
> P.S. See https://en.wikipedia.org/wiki/Zero-based_numbering

I don=E2=80=99t think changing the name changes my concern, but as Tyson
pointed out:

> These idiosyncrasies of php and unintuitive behaviors existed prior
> to this RFC.

I=E2=80=99m generally +1 on this RFC, but as I think about it, maybe =
there is a
problem with the name. If we choose to introduce a pure list construct
at some point, then `is_list()` may cause confusion (or maybe it =
won=E2=80=99t,
if it can be made to return `true` for a zero-indexed, standard PHP
array *and* a `list`, whatever that might look like in the language).

Cheers,
Ben




--Apple-Mail=_F6A222E6-ECA7-4E81-91CD-C82F4A5325DE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCX+FTqgAKCRCwLZeYnIwH
G3GkAP46LpB5ybh/IdUVJjK51bwsyTm9ExDkr7XWKEpmlX3lGQD+L+PZnjFxXOOX
n0TuMVs1G0mmoGOPoXz2nDUsvrh/zkU=
=SoQ4
-----END PGP SIGNATURE-----

--Apple-Mail=_F6A222E6-ECA7-4E81-91CD-C82F4A5325DE--