Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109789
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <31441489-11c6-4d99-9c53-6ac0e877f268@www.fastmail.com>
In-Reply-To: 
 <CAKuGYLR_GxMdyNniRW93U=tHu3xr+g0VkzzoRRoH-jQx=sVegQ@mail.gmail.com>
References: 
 <CAKuGYLSHXG=QSjPT5TCgf2KV-D+cMt=s4++sw38wy3Hwt1BuqQ@mail.gmail.com>
 <4c1cd016-1e41-4ebc-afc4-d8d3cd1c319b@www.fastmail.com>
 <CAKuGYLR_GxMdyNniRW93U=tHu3xr+g0VkzzoRRoH-jQx=sVegQ@mail.gmail.com>
Date: Wed, 22 Apr 2020 14:00:46 -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 Wed, Apr 22, 2020, at 1:49 PM, Matthew Brown wrote:
> > Is it an effective subtype of array?
>=20
> I was thinking it should be (with the auto-conversion mentioned above)=
, but
> I can see a compelling case to not have the auto-conversion when
> manipulating =E2=80=93 while it would bloat the stdlib a little (we'd =
need a whole
> bunch of list_* functions) the separation would simplify things a lot =
(e.g.
> list_filter would return a list with sequential keys, whereas array_fi=
lter
> returns an array with possibly non-sequential keys)
>=20
> And then you could cast between the two like "(list) $some_array" (whi=
ch
> would preserve order but remove keys) and "(array) $some_list" as
> necessary. There could even be some automatic list <-> array casting w=
hen
> calling functions not in strict_types mode.
>=20
> > Should they pass like arrays or like objects
>=20
> Definitely like arrays =E2=80=93 I want them to be a drop-in-replaceme=
nt for people
> who currently use arrays in places lists are more appropriate.
>=20
> > Should they be mutable or immutable
>=20
> Definitely mutable, like arrays are

That has a long list of possible issues with it relating to spooky actio=
n at a distance, depending on the passing semantics.  In some languages =
lists are immutable, and with PHP's copy-on-write it may make more sense=
 to just go immutable.

> > Are they iterable
>=20
> Yes, the keys are sequential integers
>=20
> > Does it make sense to add them without type enforcement via generics=

>=20
> Absolutely =E2=80=93 this shouldn't be tied to generics landing (which=
 I'd imagine
> is a PHP 9 feature at this point, whereas this could be a PHP 8.x feat=
ure).
>=20
> > can they be mapped/filtered/reduced
>=20
> Absolutely =E2=80=93 I think we'd have list_map, list_filter, list_red=
uce functions
> to provide that functionality.

Why duplicate all of them?  Rather, map/filter/reduce need to be recast =
to work on any iterable, which would then include lists.  Or, if lists a=
re an object they would be methods on the object.

Hence my point.  Lists would only make sense if we're also rethinking ho=
w collections work generally, for which we're already overdue.  Just tos=
sing them in as yet-another-different-thing would make the situation wor=
se, not better.

--Larry Garfield