Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126536
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 01 Mar 2025 08:37:50 +0100
To: internals@lists.php.net
Message-ID: <15994089-a8cb-4909-8f6c-b679b88efaab@app.fastmail.com>
In-Reply-To: <81F87FFD-91EF-4FDF-A929-9BE1CA08AA1E@garsi.de>
References: <81F87FFD-91EF-4FDF-A929-9BE1CA08AA1E@garsi.de>
Subject: Re: [PHP-DEV] Vibe check: array shapes
Content-Type: multipart/alternative;
 boundary=a0536a24b17d488f876bdcbd45aa5f45
From: rob@bottled.codes ("Rob Landers")

--a0536a24b17d488f876bdcbd45aa5f45
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Feb 28, 2025, at 23:52, Alwin Garside wrote:
> =EF=BB=BFHello,
>=20
> Long time listener, first time caller here.
>=20
> Last week I had a shower thought about how it would be neat if we coul=
d declare array shapes in PHP, and use them to provide structural interf=
aces for arrays.
>=20
> After all, arrays are one of PHPs strongest features, and anyone who h=
as ever tried to use arrays/maps in other languages after getting used t=
o the versatility of PHP arrays will have to admit that nothing comes cl=
ose to their flexibility and ease of use.
>=20
> However, ironically, most of my friends, colleagues and fellow PHP dev=
s usually tend to shun PHP arrays, which has led to the widespread use o=
f Collection classes and the like. The usual argument is that arrays don=
=E2=80=99t provide any way to declare their structure, and thus don=E2=80=
=99t provide the ergonomics of autocompletion (even if you declare the a=
rray shapes with docblock annotations IDE support is iffy at best) and d=
on=E2=80=99t provide any form of runtime type checking.
>=20
> To me, providing structural interfaces using shapes seems like a perfe=
ct fit to the flexibility of arrays. I imagine you'd define them in a si=
milar way to an interface, declaring and typing array elements rather th=
an methods or property hooks. They'd provide a way to validate the conte=
nts of an array at runtime, and offer static analyzers and IDEs a robust=
 way to do type inspections and provide autocompletions for arrays.
>=20
> Of course my first assumption was that other people much smarter than =
me probably already had this idea, so I started doing my due diligence a=
nd discovered that a draft for a Shapes RFC was written by Kacper Donat =
back in 2021 [1], but unfortunately seems to have since been abandoned. =
This is a shame because it lines up about 90% with my ideas of what arra=
y shapes should look like in PHP.
>=20
> I'm unable to find any reference to this RFC on the PHP Wiki nor could=
 I find any threads discussing it in the PHP-Internals archive, so I ass=
ume they simply never got around to completing it, or there was some dis=
cussion elsewhere that prompted them to abandon the RFC.
>=20
> Anyway, I would love to try and push this idea forward =E2=80=93 eithe=
r by contacting Kacpar, or writing my own RFC =E2=80=93 and have a shot =
at implementing a proof of concept, but first I would like to get a feel=
 for whether this proposal would find much footing here.
>=20
> So please let me know how you feel about the idea of array shapes in P=
HP, and perhaps read the draft written by Kacper Donat [1] for a much mo=
re eloquent example of what I'm trying to propose here.
>=20
> Thank you all very much in advance.
>=20
> Kindest regards,
> Alwin Garside
>=20
> [1] https://hackmd.io/@kadet/php-rfc-shapes
>=20

Hi Alwin,

You may be interested in http://wiki.php.net/rfc/records, whose goal fro=
m the beginning was a new type that behaved like arrays (value semantics=
, copy on write) as well as the ability to attach behavior to them.

I=E2=80=99ve since abandoned it due to the poor reception it got on the =
list and decided to pursue inner classes instead. However, I spent nearl=
y a year thinking through that RFC, so feel free to pick my brain via em=
ail, or a call.=20

The first implementation didn=E2=80=99t use classes at all, instead were=
 implemented on arrays and enforced an array shape. This meant that reco=
rds were a subtype of arrays (so you could pass a record as an argument =
in lieu of an array). This worked pretty well, but feedback I got from c=
olleagues challenged me to add the ability for behavior. So, I had to ab=
andon that implementation. So, if you look at that RFC and remove all th=
e behavior, you=E2=80=99re basically left with a record keyword and the =
ability to specify types and props.=20

The biggest challenges with that implementation (and array shapes in gen=
eral), happen to be around WHEN to do type checking and how to get a han=
dle on references. Further, there=E2=80=99s quite a few parts of php tha=
t reach into the implementation of arrays and do something different tha=
n the canonical implementation (opcache, is a good example here) that ca=
n end up breaking things in fun ways. Particularly if you somehow end up=
 with one of these in one of the magic global arrays.

Anyway, best of luck to you and don=E2=80=99t hesitate to reach out!

=E2=80=94 Rob
--a0536a24b17d488f876bdcbd45aa5f45
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Fri, Feb 28, 2025, at 23:52, Alwin Garside wrote:<br><=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>=EF=BB=BFHello,=
<br></div><div><br></div><div>Long time listener, first time caller here=
.<br></div><div><br></div><div>Last week I had a shower thought about ho=
w it would be neat if we could declare array shapes in PHP, and use them=
 to provide structural interfaces for arrays.<br></div><div><br></div><d=
iv>After all, arrays are one of PHPs strongest features, and anyone who =
has ever tried to use arrays/maps in other languages after getting used =
to the versatility of PHP arrays will have to admit that nothing comes c=
lose to their flexibility and ease of use.<br></div><div><br></div><div>=
However, ironically, most of my friends, colleagues and fellow PHP devs =
usually tend to shun PHP arrays, which has led to the widespread use of =
Collection classes and the like. The usual argument is that arrays don=E2=
=80=99t provide any way to declare their structure, and thus don=E2=80=99=
t provide the ergonomics of autocompletion (even if you declare the arra=
y shapes with docblock annotations IDE support is iffy at best) and don=E2=
=80=99t provide any form of runtime type checking.<br></div><div><br></d=
iv><div>To me, providing structural interfaces using shapes seems like a=
 perfect fit to the flexibility of arrays. I imagine you'd define them i=
n a similar way to an interface, declaring and typing array elements rat=
her than methods or property hooks. They'd provide a way to validate the=
 contents of an array at runtime, and offer static analyzers and IDEs a =
robust way to do type inspections and provide autocompletions for arrays=
.<br></div><div><br></div><div>Of course my first assumption was that ot=
her people much smarter than me probably already had this idea, so I sta=
rted doing my due diligence and discovered that a draft for a Shapes RFC=
 was written by Kacper Donat back in 2021 [1], but unfortunately seems t=
o have since been abandoned. This is a shame because it lines up about 9=
0% with my ideas of what array shapes should look like in PHP.<br></div>=
<div><br></div><div>I'm unable to find any reference to this RFC on the =
PHP Wiki nor could I find any threads discussing it in the PHP-Internals=
 archive, so I assume they simply never got around to completing it, or =
there was some discussion elsewhere that prompted them to abandon the RF=
C.<br></div><div><br></div><div>Anyway, I would love to try and push thi=
s idea forward =E2=80=93 either by contacting Kacpar, or writing my own =
RFC =E2=80=93 and have a shot at implementing a proof of concept, but fi=
rst I would like to get a feel for whether this proposal would find much=
 footing here.<br></div><div><br></div><div>So please let me know how yo=
u feel about the idea of array shapes in PHP, and perhaps read the draft=
 written by Kacper Donat [1] for a much more eloquent example of what I'=
m trying to propose here.<br></div><div><br></div><div>Thank you all ver=
y much in advance.<br></div><div><br></div><div>Kindest regards,<br></di=
v><div>Alwin Garside<br></div><div><br></div><div>[1]&nbsp;<a href=3D"ht=
tps://hackmd.io/@kadet/php-rfc-shapes">https://hackmd.io/@kadet/php-rfc-=
shapes</a><br></div><div><br></div></blockquote><div><br></div><div>Hi A=
lwin,<br></div><div><br></div><div>You may be interested in&nbsp;<a href=
=3D"http://wiki.php.net/rfc/records">http://wiki.php.net/rfc/records</a>=
, whose goal from the beginning was a new type that behaved like arrays =
(value semantics, copy on write) as well as the ability to attach behavi=
or to them.<br></div><div><br></div><div>I=E2=80=99ve since abandoned it=
 due to the poor reception it got on the list and decided to pursue inne=
r classes instead. However, I spent nearly a year thinking through that =
RFC, so feel free to pick my brain via email, or a call.&nbsp;<br></div>=
<div><br></div><div>The first implementation didn=E2=80=99t use classes =
at all, instead were implemented on arrays and enforced an array shape. =
This meant that records were a subtype of arrays (so you could pass a re=
cord as an argument in lieu of an array). This worked pretty well, but f=
eedback I got from colleagues challenged me to add the ability for behav=
ior. So, I had to abandon that implementation. So, if you look at that R=
FC and remove all the behavior, you=E2=80=99re basically left with a rec=
ord keyword and the ability to specify types and props.&nbsp;<br></div><=
div><br></div><div>The biggest challenges with that implementation (and =
array shapes in general), happen to be around WHEN to do type checking a=
nd how to get a handle on references. Further, there=E2=80=99s quite a f=
ew parts of php that reach into the implementation of arrays and do some=
thing different than the canonical implementation (opcache, is a good ex=
ample here) that can end up breaking things in fun ways. Particularly if=
 you somehow end up with one of these in one of the magic global arrays.=
<br></div><div><br></div><div>Anyway, best of luck to you and don=E2=80=99=
t hesitate to reach out!</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob<br></div></body></html>
--a0536a24b17d488f876bdcbd45aa5f45--