Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126534
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [PHP-DEV] Vibe check: array shapes
In-Reply-To: <86f10d5a-c7d0-4592-900f-fdcd11b8ff3c@app.fastmail.com>
Date: Sat, 1 Mar 2025 02:31:53 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <CD10EF4B-1FD9-4BDE-A643-D3EE9ABF36B7@garsi.de>
References: <81F87FFD-91EF-4FDF-A929-9BE1CA08AA1E@garsi.de>
 <86f10d5a-c7d0-4592-900f-fdcd11b8ff3c@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: alwin@garsi.de (Alwin Garside)

On 1 Mar 2025, at 00:28, Larry Garfield <larry@garfieldtech.com> wrote:
> Your friends are correct.  Arrays in PHP are an awful thing.  They are =
twice as memory hungry as objects, they provide no static guarantees, =
and they're a security hole waiting to happen (and has in fact =
happened).
>=20
> And since PHP 8.0, *we have something equivalent to array shapes =
already that is vastly more efficient*: Constructor promotion.
>=20
> // This tells me nothing.
> $arrayPoint =3D ['x' =3D> 1, 'y' =3D> 2];
>=20
> // This tells me everything.
> class Point {
>  public function __construct(
>    public int $x,
>    public int $y,
>  ) {}
> }
> $objectPoint =3D new Point(x: 1, y: 2);
>=20
> $objectPoint will use half as much memory as $arrayPoint.  (Not =
meaningful in something this small, but if you have 100 of them...)  It =
provides all the static type validation you can get in PHP right now.  =
It's self-documenting.  It works with everything else in the language.  =
And it's already been available for 5 years.  And now you can also toss =
readonly, private(set), or hooks around on it if you feel like it.
>=20
> This is a solved problem, and the solution is objects.  Using arrays =
as pseudo-objects is the wrong approach 99.9% of the time.  Collections =
are a different matter, as those are real lists.
>=20
> For more details: https://www.youtube.com/watch?v=3DnNtulOOZ0GY
>=20
> All that said!
>=20
> A side effect of the pattern matching RFC (which we'll be formally =
proposing real-soon-now-I-swear) is that it effectively gives an =
array-shape validation check for free.
>=20
> https://wiki.php.net/rfc/pattern-matching
>=20
> So yeah, no thank you on a separate array shapes RFC.
>=20
> --Larry Garfield

I get you. Used analogously to objects, arrays are indeed awful by =
comparison.

However, arrays are very ergonomic to work with, especially for passing =
along a list of properties, which is why many frameworks and libraries =
still use them.

The combination of constructor promotion, named arguments and property =
hooks (thank you for those btw!) have definitely helped to make classes =
more usable in this regard, but they are still too "rigid" compared to =
structural interfaces as in, for example, TypeScript.

Consider if you have several interface defined for a set of options, =
you'll always need to declare a class to actually implement them.

    interface ALotOfOptions {
        public int $this { get; }
        public ?float $that { get; }
        public ?string $then { get; }
        public ?string $there { get; }
        // [...]
    }
   =20
    interface AdditionalOptions {
        public ?string $thisToo { get; }
    }
   =20
    class AllTheOptions implements ALotOfOptions, AdditionalOptions {
        public __construct(
            public int $this { get; }
            public ?float $that { get; }
            public ?string $then { get; }
            public ?string $there { get; }
            // [...]
            public ?string $thisToo { get; }
        )
    }
   =20
    $options =3D new AllTheOptions(
        this:  42,
        that:  1.337,
        there: 'here',
        // [...]
    );
   =20
    function iWantOptions(ALotOfOptions & AdditionalOptions $options) { =
... }

I guess you _could_ do this with anonymous classes, but that doesn't =
make things any prettier.

With my hypothetical shapes you'd declare a structural interface, and =
both implement and instantiate it at the same time by initializing an =
array.

    shape ALotOfOptions {
        'this':  int;
        'that':  ?float;
        'then':  ?string;
        'there': ?string;
        // [...]
    }
   =20
    shape AdditionalOptions {
        'thisToo': ?string;
    }
   =20
    $options =3D [
        'this'  =3D> 42,
        'that'  =3D> 1.337,
        'there' =3D> 'here',
        // [...]
    ];
   =20
    function iWantOptions(ALotOfOptions & AdditionalOptions $options) { =
... }

As you can see, there is a less boilerplate code, and it becomes easier =
to combine sets of options. This is a very popular pattern in =
TypeScript, for example when working with AWS CDK, and in my experience =
it is very ergonomic to work with.

Are PHP arrays the ideal solution for this? No, not really. But at the =
moment they are the only realistic option if you want to provide a =
flexible and ergonomic solution. I know arrays are inferior to objects =
in terms of type-safety and memory consumption, but they have their =
legit use cases (besides serving as glorified lists), and often are =
simply the more ergonomic option. The truth of the matter is, arrays =
aren't going anywhere anytime soon, and I think it would not be a bad =
idea to at least make them less treacherous to work with for the people =
that have legit use cases for them.

Having said all that!

After Tim suggested your RFC I have taken a better look, and patterns =
are indeed a very interesting proposition. However, for pattern matching =
to cover my wishes regarding arrays shapes would depend on several =
features described as future scopes, namely 'Optional array key marker' =
and 'Patterns as variables/types'. Plus I'm a bit unclear about what the =
syntax would exactly look like. =46rom what I can gather it would look =
something like this:

    pattern [
        'this' =3D> int,
        ?'that' =3D> float,
        ?'then' =3D> string,
        ?'there' =3D> string,
        // [...]
    ] as ALotOfOptions;
   =20
    pattern [
        ?'thisToo': string,
    ] as AdditionalOptions;

I'm not too sure how I feel about the `as` keyword at the end... But =
that's a story for a different thread.

At any rate, it's clear that Pattern Matching makes any array shape RFC =
completely redundant.

I'll be rooting for the Pattern Matching RFC! Seems like it would be a =
very powerful addition to PHP. And I hope that the future scopes I =
mentioned will find their way to their own respective RFC(s) soon after, =
then everybody will be happy. :-)

Alwin=