Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122897
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LA7kJLdz3Pzbxr6x-7v2YV8n06pwxs6QoVe3CGgx-_GGA@mail.gmail.com>
 <1a4a44c5-d4f5-40ca-b3dc-13d64c2b4425@app.fastmail.com>
In-Reply-To: <1a4a44c5-d4f5-40ca-b3dc-13d64c2b4425@app.fastmail.com>
Date: Tue, 2 Apr 2024 17:49:02 -0300
Message-ID: <CADK1yXLmuAf6oWa9NMOZy_Xm6eqeY3mbwKVGkxKQVOjoombbvA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000094ef980615233e87"
From: deleugyn@gmail.com (Deleu)

--00000000000094ef980615233e87
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024 at 1:47=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om>
wrote:

> > * Data classes protect from interior mutability. More concretely,
> > mutating nested data objects stored in a `readonly` property is not
> > legal, whereas it would be if they were ordinary objects.
> > * In the future, it should be possible to allow using data classes in
> > `SplObjectStorage`. However, because hashing is complex, this will be
> > postponed to a separate RFC.
>
> Would data class properties only be allowed to be other data classes, or
> could they hold a non-data class?  My knee jerk response is they should b=
e
> data classes all the way down; the only counter-argument I can think of i=
t
> would be how much existing code is out there that is a "data class" in al=
l
> but name.  I still fear someone adding a DB connection object to a data
> class and everything going to hell, though. :-)
>

If there is a class made up of 90% data struct and 10% non-data struct, the
90% could be extracted into a true data struct and be referenced in the
existing regular class, making it even more organized in terms of
establishing what's "data" and what's "service". I would really favor
making it "data class" all the way down.

I understand you disagree with the argument against inheritance, but to me
the same logic applies here. Making it data class only allows for lifting
the restriction in the future, if necessary (requiring another RFC vote).
Making it mixed on version 1 means that support for the mixture of them can
never be undone.


--=20
Marco Deleu

--00000000000094ef980615233e87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 2, 2024 at 1:47=E2=80=AFP=
M Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfie=
ldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">&gt; * Data classes protect from interior mutability. More concr=
etely,<br>
&gt; mutating nested data objects stored in a `readonly` property is not<br=
>
&gt; legal, whereas it would be if they were ordinary objects.<br>
&gt; * In the future, it should be possible to allow using data classes in<=
br>
&gt; `SplObjectStorage`. However, because hashing is complex, this will be<=
br>
&gt; postponed to a separate RFC.<br>
<br>
Would data class properties only be allowed to be other data classes, or co=
uld they hold a non-data class?=C2=A0 My knee jerk response is they should =
be data classes all the way down; the only counter-argument I can think of =
it would be how much existing code is out there that is a &quot;data class&=
quot; in all but name.=C2=A0 I still fear someone adding a DB connection ob=
ject to a data class and everything going to hell, though. :-)<br></blockqu=
ote><div><br></div><div>If there is a class made up of 90% data struct and =
10% non-data struct, the 90% could be extracted into a true data struct and=
 be referenced in the existing regular class, making it even more organized=
 in terms of establishing what&#39;s &quot;data&quot; and what&#39;s &quot;=
service&quot;. I would really favor making it &quot;data class&quot; all th=
e way down.</div><div><br></div><div>I understand you disagree with the arg=
ument against inheritance, but to me the same logic applies here. Making it=
 data class only allows for lifting the restriction in the future, if neces=
sary (requiring another RFC vote). Making it mixed on version 1 means that =
support for the mixture of them can never be undone.=C2=A0</div></div><br c=
lear=3D"all"><div><br></div><span class=3D"gmail_signature_prefix">-- </spa=
n><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div dir=
=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr=
"><div dir=3D"ltr">Marco Deleu</div></div></div></div></div></div></div></d=
iv></div>

--00000000000094ef980615233e87--