Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109788
MIME-Version: 1.0
References: <CAKuGYLSHXG=QSjPT5TCgf2KV-D+cMt=s4++sw38wy3Hwt1BuqQ@mail.gmail.com>
 <4c1cd016-1e41-4ebc-afc4-d8d3cd1c319b@www.fastmail.com>
In-Reply-To: <4c1cd016-1e41-4ebc-afc4-d8d3cd1c319b@www.fastmail.com>
Date: Wed, 22 Apr 2020 14:49:17 -0400
Message-ID: <CAKuGYLR_GxMdyNniRW93U=tHu3xr+g0VkzzoRRoH-jQx=sVegQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a4a88a05a3e59744"
Subject: Re: [PHP-DEV] Any interest in a list type?
From: matthewmatthew@gmail.com (Matthew Brown)

--000000000000a4a88a05a3e59744
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Is it an effective subtype of array?

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_filter
returns an array with possibly non-sequential keys)

And then you could cast between the two like "(list) $some_array" (which
would preserve order but remove keys) and "(array) $some_list" as
necessary. There could even be some automatic list <-> array casting when
calling functions not in strict_types mode.

> Should they pass like arrays or like objects

Definitely like arrays =E2=80=93 I want them to be a drop-in-replacement fo=
r people
who currently use arrays in places lists are more appropriate.

> Should they be mutable or immutable

Definitely mutable, like arrays are

> Are they iterable

Yes, the keys are sequential integers

> Does it make sense to add them without type enforcement via generics

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 feature).

> can they be mapped/filtered/reduced

Absolutely =E2=80=93 I think we'd have list_map, list_filter, list_reduce f=
unctions
to provide that functionality.

On Wed, 22 Apr 2020 at 13:28, Larry Garfield <larry@garfieldtech.com> wrote=
:

> 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 list
> > type?
> >
> > 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
> arrays
> > 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.
> >
> > 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
> >
> > $l =3D list["a", "b", "c"];
> >
> > I imagine such a "list" type would be a subtype of "array" =E2=80=93 ev=
erywhere
> > that array was accepted, a list would be also, and it would have the sa=
me
> > copy-on-write behaviour.
> >
> > If people are interested in having that type, there's a question of wha=
t
> to
> > do with
> >
> > $some_list["a"] =3D 5;
> >
> > 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.
> >
> > Similarly, the behaviour of
> >
> > $some_list[$key_out_of_current_range] =3D 5
> >
> > would be a matter of debate too =E2=80=93 would that turn $some_list in=
to an
> array,
> > or would it fill up any preceding entries in the array with null?
> >
> > What other questions are there? Is a "list" type even a good fit for PH=
P,
> > 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
> dangerous 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 particular:
>
> * Is it an effective subclass of array?  IMO, no.  It should have
> absolutely 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 f=
ly
> 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
> effectively, I think, though I'd honestly favor immutable.
>
> * Are they iterable?  Presumably, but does that have any weird
> implications for iterables that implicitly assume there are keys?  How's
> that work?
>
> * 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(tm)
> and Not Imminent(tm).  But would adding them now make a generic version
> harder in the future?  (I've no idea.)
>
> * Besides add/remove/iterate, what other baked-in functionality should
> they 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
> talking about comprehensions and stuff here.)  Ideally this would happen =
as
> part of a larger review of how collections work at various levels, which
> 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 implementatio=
n
> could be viable.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000a4a88a05a3e59744--