Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109790
MIME-Version: 1.0
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>
 <31441489-11c6-4d99-9c53-6ac0e877f268@www.fastmail.com>
In-Reply-To: <31441489-11c6-4d99-9c53-6ac0e877f268@www.fastmail.com>
Date: Wed, 22 Apr 2020 16:44:58 -0400
Message-ID: <CAKuGYLT8Ros+bQtuuLmNWYsGLjzNJVUeChEyHH0k3bR4fRPb9Q@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003cd0c405a3e7358a"
Subject: Re: [PHP-DEV] Any interest in a list type?
From: matthewmatthew@gmail.com (Matthew Brown)

--0000000000003cd0c405a3e7358a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> map/filter/reduce need to be recast to work on any iterable, which would
then include lists
> Lists would only make sense if we're also rethinking how collections work
generally

I disagree =E2=80=93 I think the most successful PHP language additions hav=
e been
those that allow PHP developers to improve their code without having to
think too hard =E2=80=93 for example, property, return and param types can =
be added
to existing code without changing its behaviour at runtime, as long as the
added types align with actual behaviour.

If list types work in a wholly different fashion to arrays, they won't be a
drop-in-replacement, they won't feel familiar to the average PHP developer,
and I imagine few people would update existing code to use them, because
it'd be too risky.

On Wed, 22 Apr 2020 at 15:01, Larry Garfield <larry@garfieldtech.com> wrote=
:

> On Wed, Apr 22, 2020, at 1:49 PM, Matthew Brown wrote:
> > > 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 n=
eed 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" (whic=
h
> > would preserve order but remove keys) and "(array) $some_list" as
> > necessary. There could even be some automatic list <-> array casting wh=
en
> > 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-replacemen=
t for
> people
> > who currently use arrays in places lists are more appropriate.
> >
> > > Should they be mutable or immutable
> >
> > Definitely mutable, like arrays are
>
> That has a long list of possible issues with it relating to spooky action
> at a distance, depending on the passing semantics.  In some languages lis=
ts
> are immutable, and with PHP's copy-on-write it may make more sense to jus=
t
> go immutable.
>
> > > 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_redu=
ce
> functions
> > to provide that functionality.
>
> Why duplicate all of them?  Rather, map/filter/reduce need to be recast t=
o
> work on any iterable, which would then include lists.  Or, if lists are a=
n
> object they would be methods on the object.
>
> Hence my point.  Lists would only make sense if we're also rethinking how
> collections work generally, for which we're already overdue.  Just tossin=
g
> them in as yet-another-different-thing would make the situation worse, no=
t
> better.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0000000000003cd0c405a3e7358a--