Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121026
MIME-Version: 1.0
References: <b22fd483-de4d-3876-eac8-305e62245cf0@online-presence.ca> <CA+p1FaZ-LTCaYdNsBw_PLtL5mj9f1EEXZEjzzSczJ0748f-Yog@mail.gmail.com>
In-Reply-To: <CA+p1FaZ-LTCaYdNsBw_PLtL5mj9f1EEXZEjzzSczJ0748f-Yog@mail.gmail.com>
Date: Sat, 9 Sep 2023 09:14:02 +0200
Message-ID: <CAPzBOBOwf8cWbP+c7TwaAd-RBQx8KkO0x7puUtZLi3X_ouiHhA@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
From: landers.robert@gmail.com (Robert Landers)

On Sat, Sep 9, 2023 at 1:09=E2=80=AFAM David Gebler <davidgebler@gmail.com>=
 wrote:
>
> On Fri, Sep 8, 2023 at 2:12=E2=80=AFPM Lanre Waju <lanre@online-presence.=
ca> wrote:
>
> > Dear PHP Internals,
> >
> > I am writing to propose a new feature for PHP that introduces the
> > concept of structs. This feature aims to provide a more concise and
> > expressive way to define and work with immutable data structures. Below
> > is a detailed description of the proposed syntax, usage, and behavior.
> >
> > Syntax
> >
> > struct Data
> > {
> >      string $title;
> >      Status $status;
> >      ?DateTimeImmutable $publishedAt =3D null;
> > }
> > The Data struct is essentially represented as a readonly class with a
> > constructor as follows:
> >
> >
> > readonly class Data
> > {
> >      public function __construct(
> >          public string $title,
> >          public Status $status,
> >          public ?DateTimeImmutable $publishedAt =3D null,
> >      ) {}
> > }
> >
>
> These as the most basic examples of what you're proposing are barely
> different expressions in length, let alone anything else. I wouldn't say
> the first example is particularly more helpful, more readable, more conci=
se
> or conceptually more expressive than the second. The rest of your example=
s
> are similarly either very minor savings of a few characters shaved off he=
re
> and there, or just as verbose as instantiating a class with a constructor
> anyway.
>
> I'm not convinced by the rationale that this would be a new feature
> worthwhile for improved expression or concision. I can see a potential
> benefit in these "structs" (not sure that's the term//keyword I'd choose,
> given it has different meanings in other languages) though, as a kind of
> template for properly structured arrays, with a built-in ability to cast
> them to arrays or treat them as arrays/iterables. This would potentially
> help give some of the power we're missing by not having generics. So it
> wouldn't just be equivalent to a shorthand for a readonly class with a
> constructor, but one which also satisfied a couple of interfaces with the
> implementation automatically provided.
>
> That's my initial reaction/two cents.
>
> -Dave

Indeed,

When I first saw this, I saw them as typed-arrays, and it would be
great if they were treated as such. Essentially, type-check, then
stored in a regular array and as far as the engine is concerned,
that's what they are (meaning they could be used when a library
expects an array, or gradually added to legacy code that passes around
opaque arrays). This could add a tremendous amount of expressibility
to PHP. This would mean a struct with the same properties and values
are equal. It'd be even awesome if you could cast between structs (and
to arrays), as long as the struct/array being casted from contained
all the right properties/values. For example:

$myStruct1 =3D (MyStruct1) $myStruct2; // myStruct2 could even be an
array, or another struct

is the same as:

$myStruct1 =3D new MyStruct1(...$myStruct2);

except ignoring extra properties/values. Maybe the casting could even
"hide" the extra properties in a private variable so that if it is
casted to an array, or serialized as json, or casted to a different
struct, the original data shows up.

As far as being able to increase the expression of regular 'ole PHP,
it would allow libraries to get rid of opaque arrays with hidden
options (looking at you Guzzle), and essentially not change but a few
lines of code, while making it easy for users to correctly use the
library.

Anyway, just thinking out loud. I have no idea if the original author
has an intent for any of this, but it could be awesome.

Robert Landers
Software Engineer
Utrecht NL