Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126035
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 23 Nov 2024 17:05:04 +0100
To: internals@lists.php.net
Message-ID: <0b87a3eb-7e63-4e28-a11d-25824e240a73@app.fastmail.com>
In-Reply-To: <163a08c1-2279-4a3f-a1bb-8cdfe406a4ba@rwec.co.uk>
References: <18b85ba5-5f1c-489c-9096-3ae203977fbe@app.fastmail.com>
 <163a08c1-2279-4a3f-a1bb-8cdfe406a4ba@rwec.co.uk>
Subject: Re: [PHP-DEV] [RFC] Data Classes
Content-Type: multipart/alternative;
 boundary=cd5b58dd656a462fbffec40706c225da
From: rob@bottled.codes ("Rob Landers")

--cd5b58dd656a462fbffec40706c225da
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 23, 2024, at 16:22, Rowan Tommins [IMSoP] wrote:
> On 23/11/2024 13:11, Rob Landers wrote:
>> Born from the Records RFC (https://wiki.php.net/rfc/records) discussi=
on, I would like to introduce to you a competing RFC: Data Classes (http=
s://wiki.php.net/rfc/dataclass).
>=20
>=20
> Thank you for continuing to think about this, and PoC code is always u=
seful to work through the implications.
>=20
> It seems like this is going in a very similar direction to the work Il=
ija shared in April: https://externals.io/message/122845 and https://git=
hub.com/php/php-src/pull/13800
>=20
> My knowledge of the engine isn't good enough to compare the two PRs, b=
ut the descriptions seem very similar. The main differences seem to be d=
etails mentioned in one draft and not the other:
>=20
>=20
> - You have described details for constructors and inheritance, which I=
lija left as open questions
> - Ilija had considered how instance methods should behave, proposing a=
 "mutating" keyword and "!" call-site marker. Your RFC doesn't discuss t=
his - the changeName example shows behaviour *inside* the method, but no=
t behaviour when *calling* it
>=20
> Is it just an oversight that you didn't link to the previous discussio=
n, or had you not realised how similar the proposals would end up? Eithe=
r way, this looks like ripe ground for collaboration, unless there is so=
me fundamental disagreement about the approach.
>=20
>=20
>=20
> --=20
> Rowan Tommins
> [IMSoP]

Yes, this is mostly about "composability" vs. dedicated syntax. A bare "=
data class" is very similar to struct while a "final readonly data class=
" is very similar to records.

> Is it just an oversight that you didn't link to the previous
>       discussion, or had you not realised how similar the proposals
>       would end up?

Yes, it is an oversight! I didn't even think to link to it. To be fair, =
I also didn't link to the records RFC. I've updated the RFC with links. =
While some behavior is similar to what Ilija described, it is mostly a n=
atural progression of adding a `data` modifier to classes. There's no sp=
ecial syntax because classes already have a well-defined syntax.

> Your RFC
>       doesn't discuss this - the changeName example shows behaviour
>       *inside* the method, but not behaviour when *calling* it

An interesting observation, can you explain more as to what you mean? Th=
e changeName example is simply about constructors=E2=80=94whose behavior=
 is mostly due to engine limitations. You can't very easily see what hap=
pens inside a constructor from outside a constructor (usually).

=E2=80=94 Rob
--cd5b58dd656a462fbffec40706c225da
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">=0Ap.=
MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sat, Nov =
23, 2024, at 16:22, Rowan Tommins [IMSoP] wrote:<br></div><blockquote ty=
pe=3D"cite" id=3D"qt" style=3D""><div class=3D"qt-moz-cite-prefix">On 23=
/11/2024 13:11, Rob Landers wrote:<br></div><blockquote type=3D"cite" ci=
te=3D"mid:18b85ba5-5f1c-489c-9096-3ae203977fbe@app.fastmail.com"><div>Bo=
rn from the Records RFC (<a href=3D"https://wiki.php.net/rfc/records" cl=
ass=3D"qt-moz-txt-link-freetext">https://wiki.php.net/rfc/records</a>)=0A=
        discussion, I would like to introduce to you a competing RFC:=0A=
        Data Classes (<a href=3D"https://wiki.php.net/rfc/dataclass" cla=
ss=3D"qt-moz-txt-link-freetext">https://wiki.php.net/rfc/dataclass</a>).=
<br></div></blockquote><p><br></p><p>Thank you for continuing to think a=
bout this, and PoC code is=0A      always useful to work through the imp=
lications.<br></p><p>It seems like this is going in a very similar direc=
tion to the=0A      work Ilija shared in April: <a class=3D"qt-moz-txt-l=
ink-freetext" href=3D"https://externals.io/message/122845">https://exter=
nals.io/message/122845</a> and <a class=3D"qt-moz-txt-link-freetext" hre=
f=3D"https://github.com/php/php-src/pull/13800">https://github.com/php/p=
hp-src/pull/13800</a><br></p><p>My knowledge of the engine isn't good en=
ough to compare the two=0A      PRs, but the descriptions seem very simi=
lar. The main differences=0A      seem to be details mentioned in one dr=
aft and not the other:<br></p><p></p><div>- You have described details f=
or constructors and inheritance,=0A      which Ilija left as open questi=
ons<br></div><div> - Ilija had considered how instance methods should be=
have,=0A      proposing a "mutating" keyword and "!" call-site marker. Y=
our RFC=0A      doesn't discuss this - the changeName example shows beha=
viour=0A      *inside* the method, but not behaviour when *calling* it<b=
r></div><p></p><p>Is it just an oversight that you didn't link to the pr=
evious=0A      discussion, or had you not realised how similar the propo=
sals=0A      would end up? Either way, this looks like ripe ground for=0A=
      collaboration, unless there is some fundamental disagreement about=
=0A      the approach.<br></p><p><br></p><pre class=3D"qt-moz-signature"=
 cols=3D"72">--=20=0ARowan Tommins=0A[IMSoP]<br></pre></blockquote><div>=
<br></div><div>Yes, this is mostly about "composability" vs. dedicated s=
yntax. A bare "data class" is very similar to&nbsp;struct while a "final=
 readonly data class" is very similar to records.<br></div><div><br></di=
v><blockquote type=3D"cite"><div>Is it just an oversight that you didn't=
 link to the previous<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; discu=
ssion, or had you not realised how similar the proposals<br style=3D"max=
-width:100%;height:auto;"></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; woul=
d end up?<br></div></blockquote><div><br></div><div>Yes, it is an oversi=
ght! I didn't even think to link to it. To be fair, I also didn't link t=
o the records RFC. I've updated the RFC with links. While some behavior =
is similar to what&nbsp;Ilija described, it is mostly a natural progress=
ion of adding a `data` modifier to classes. There's no special syntax be=
cause classes already have a well-defined syntax.<br></div><div><br></di=
v><blockquote type=3D"cite"><div>Your RFC<br></div><div>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; doesn't discuss this - the changeName example shows behav=
iour<br style=3D"max-width:100%;height:auto;"></div><div>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; *inside* the method, but not behaviour when *calling* it=
<br></div></blockquote><div><br></div><div>An interesting observation, c=
an you explain more as to what you mean? The changeName example is simpl=
y about constructors=E2=80=94whose behavior is mostly due to engine limi=
tations. You can't very easily see what happens inside a constructor fro=
m outside a constructor (usually).<br></div><div><br></div><div id=3D"si=
g121229152">=E2=80=94 Rob<br></div></body></html>
--cd5b58dd656a462fbffec40706c225da--