Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109781
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <4c1cd016-1e41-4ebc-afc4-d8d3cd1c319b@www.fastmail.com>
In-Reply-To: 
 <CAKuGYLSHXG=QSjPT5TCgf2KV-D+cMt=s4++sw38wy3Hwt1BuqQ@mail.gmail.com>
References: 
 <CAKuGYLSHXG=QSjPT5TCgf2KV-D+cMt=s4++sw38wy3Hwt1BuqQ@mail.gmail.com>
Date: Wed, 22 Apr 2020 12:28:00 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Any interest in a list type?
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 21, 2020, at 2:00 PM, Matthew Brown wrote:
> Before I create an RFC or attempt a reference implementation, is there=
 any
> interest in adding (and then obviously supporting in perpetuity) a lis=
t
> type?
>=20
> The first line of PHP's documentation for "array" states: "An array in=
 PHP
> is actually an ordered map". There are some optimisations that make ar=
rays
> with ordered integer keys faster, but I'd be interested in a separate =
type
> dedicated to *sequential* integer keys. Such a type would presumably
> consume a little less memory.
>=20
> Why "list" and not "vec" or similar? "list" is also a reserved word =E2=
=80=93 I'm
> imagining that you'd construct a list like
>=20
> $l =3D list["a", "b", "c"];
>=20
> I imagine such a "list" type would be a subtype of "array" =E2=80=93 e=
verywhere
> that array was accepted, a list would be also, and it would have the s=
ame
> copy-on-write behaviour.
>=20
> If people are interested in having that type, there's a question of wh=
at to
> do with
>=20
> $some_list["a"] =3D 5;
>=20
> Would you convert the $some_list to an array, or throw an exception?
> Converting to an array would seem the more PHP-like thing to do.
>=20
> Similarly, the behaviour of
>=20
> $some_list[$key_out_of_current_range] =3D 5
>=20
> would be a matter of debate too =E2=80=93 would that turn $some_list i=
nto an array,
> or would it fill up any preceding entries in the array with null?
>=20
> What other questions are there? Is a "list" type even a good fit for P=
HP,
> given most of its users seem pretty content with the current
> swiss-army-knife array type?

Most users don't realize that PHP's arrays-not-really-arrays have caused=
 millions of dollars in security breaches in the past. :-)  They're dang=
erous and to be avoided whenever possible.

I'm very open to a list/sequence type, but as others have noted there's =
a whole crapload of details to sort out to make it viable.  In particula=
r:

* Is it an effective subclass of array?  IMO, no.  It should have absolu=
tely no auto-conversion to/from an array whatsoever of any kind, period.=
  Keep them as separate as possible.

* Should it even have random-access indexes?  Honestly I'd say no; Just =
support adding, removing, and iteration and generate the indexes on the =
fly when iterating if necessary.

* Should they pass like arrays or like objects?  Many questions here.

* Should they be mutable or immutable?  I could argue for either one eff=
ectively, I think, though I'd honestly favor immutable.

* Are they iterable?  Presumably, but does that have any weird implicati=
ons for iterables that implicitly assume there are keys?  How's that wor=
k?

* Does it make sense to add them without type enforcement via generics? =
 Lists + Generics would be lovely, but as we've seen Generics are Hard(t=
m) and Not Imminent(tm).  But would adding them now make a generic versi=
on harder in the future?  (I've no idea.)

* Besides add/remove/iterate, what other baked-in functionality should t=
hey have?  Eg, can they be mapped/filtered/reduced?  It would really suc=
k to revisit lists and not fix that disconnect in the API.  (Insert me t=
alking about comprehensions and stuff here.)  Ideally this would happen =
as part of a larger review of how collections work at various levels, wh=
ich are currently highly clunky.

Those are all solvable problems (and I've likely forgotten several), but=
 they would have to be thought through extensively before an implementat=
ion could be viable.

--Larry Garfield