Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109816
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <5766b2bc-bd82-4217-9547-6d8234258d1c@www.fastmail.com>
In-Reply-To: 
 <CAKuGYLTBdGcQVJGpoN=jhv47PUA6DKwcqD8AUUvoht+j_6RKuQ@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>
 <31441489-11c6-4d99-9c53-6ac0e877f268@www.fastmail.com>
 <CAKuGYLT8Ros+bQtuuLmNWYsGLjzNJVUeChEyHH0k3bR4fRPb9Q@mail.gmail.com>
 <73b33704-ded2-4cbc-93bd-17e8874177f2@www.fastmail.com>
 <CAKuGYLTBdGcQVJGpoN=jhv47PUA6DKwcqD8AUUvoht+j_6RKuQ@mail.gmail.com>
Date: Thu, 23 Apr 2020 10:58:08 -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 Thu, Apr 23, 2020, at 12:02 AM, Matthew Brown wrote:
> > This is the *design* process for a language, and it's important...
> Stepping back to reconsider how collections work generally, and how we=
 can
> improve them in a graceful way that leads to a clean end-state, would =
be
> very valuable.
>=20
> Though you have much more experience with internals than I do, I think=
 that
> building a consensus around a bold new vision for PHP collections woul=
d be
> a near-Sisyphean task.

Disclosure: I've been around the list for over a decade and talked a lot=
, but the recent pipe RFC is my first core patch. I'm still one of the l=
ittle people around here. :-)  Though I have successfully engaged in Sis=
yphean tasks before.  (GoPHP5, Drupal 8, FIG, etc.)

> Adding a list/vector type would be a much smaller, more easily definab=
le
> task =E2=80=93 it was one of the first new types that Hack added, and =
by all
> accounts they're pretty happy with that decision.

I think we may be talking past each other.  I don't mean "rewrite all th=
e things."  Just taking the time to think through "if we have a list typ=
e, generators, and array/dicts, what should all of the ancillary bits ar=
ound them be to make them as smooth as possible?"  Viz, how do we NOT ha=
ve array_map, list_map, and generator_map as 3 separate functions, becau=
se that would be awful.  Are list generators and array/dict generators d=
ifferent things or the same thing, or...?  Would comprehensions make sen=
se as part of such a plan?  (IMO yes.)  But then, do comprehensions prod=
uce lists or dicts or...? =20

That's the sort of knock-on effects that should be thought through befor=
e we commit code, because in the long run it would reduce the amount of =
code to commit (and the amount of WTF for users).

--Larry Garfield