Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116092
MIME-Version: 1.0
References: <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <b51e40d2-0e31-4b28-ba7d-0237ed831bde@www.fastmail.com> <DM6PR07MB661871FD349540EB1CEECF35F9DE9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <29eb9519-ab67-44b2-9d62-9c591715946a@www.fastmail.com>
In-Reply-To: <29eb9519-ab67-44b2-9d62-9c591715946a@www.fastmail.com>
Date: Sat, 18 Sep 2021 16:53:15 -0400
Message-ID: <CAKuGYLRgH3Hj485ceukx7kHjgV3Qm3Ky1sOAbn22gRU-hQR9SA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000515ddb05cc4b3de6"
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: matthewmatthew@gmail.com (Matthew Brown)

--000000000000515ddb05cc4b3de6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 18 Sept 2021 at 12:04, Larry Garfield <larry@garfieldtech.com>
wrote:

>
> I am frequently on-record hating on PHP arrays, and stating that I want
> something better.  The problems with PHP arrays include:
>
> 1. They're badly performing (because they cannot be optimized)
> 2. They're not type safe
> 3. They're mutable
> 4. They mix sequences (true arrays) with dictionaries/hashmaps, making
> everything uglier
> 5. People keep using them as structs, when they're not
> 6. The API around them is procedural, inconsistent, and overall gross
> 7. They lack a lot of native shorthand operations found in other language=
s
> (eg, slicing)
> 8. Their error handling is crap
>
> Any new native/stdlib alternative to arrays needs to address at least hal=
f
> of those issues, preferably most/all.
>

Hey Larry,

I believe 1. and 2. are an impossible standard for any PHP-based proposal
to meet. If you want it to be (runtime) type-safe, that assumes the
existence of runtime type checks which can quickly become a performance
bottleneck.

For 3, having explored immutability in depth with Psalm, arrays don't
present any sort of challenge due to their copy-on-write behavior. There's
a chunk of Psalm's codebase that makes heavy use of arrays, and it's
still provably pure.

5: they're used as makeshift structs, but there's nothing preventing people
using constructor property promotion and named parameters to model the same
data. I think this is effectively a solved problem.

No real debates about the 4, 6, 7 and 8, but I'm radically opposed to
throwing out the baby with the bathwater here =E2=80=94 languages that have=
 solved
these problems exist, but demanding a proposal pass a purity test means the
PHP project is more likely to stay the way it is.

Best wishes,

Matt

--000000000000515ddb05cc4b3de6--