Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109792
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <73b33704-ded2-4cbc-93bd-17e8874177f2@www.fastmail.com>
In-Reply-To: 
 <CAKuGYLT8Ros+bQtuuLmNWYsGLjzNJVUeChEyHH0k3bR4fRPb9Q@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>
Date: Wed, 22 Apr 2020 17:47: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 Wed, Apr 22, 2020, at 3:44 PM, Matthew Brown wrote:
> > map/filter/reduce need to be recast to work on any iterable, which w=
ould
> then include lists
> > Lists would only make sense if we're also rethinking how collections=
 work
> generally
>=20
> I disagree =E2=80=93 I think the most successful PHP language addition=
s have been
> those that allow PHP developers to improve their code without having t=
o
> 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.
>=20
> 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 devel=
oper,
> and I imagine few people would update existing code to use them, becau=
se
> it'd be too risky.

1) Please don't top-post.

2) I don't mean "make them as unlike arrays as possible".  I mean "think=
 through the implications of having a *third* type of iterable; what oth=
er functions would be affected?  Should we reconsider how map/filter/red=
uce work generally instead of just throwing a bunch more random function=
s at it?  What are the knock-on effects?  Should we also be adding a ded=
icated dictionary type as well?  Why or why not?"

This is the *design* process for a language, and it's important.  "Let's=
 just throw a numeric-only list type into the pool and see what happens"=
 is a very bad idea.  Stepping back to reconsider how collections work g=
enerally, and how we can improve them in a graceful way that leads to a =
clean end-state, would be very valuable.

--Larry Garfield