Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125978
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 17 Nov 2024 22:30:24 +0100
To: internals@lists.php.net
Message-ID: <ab3e32e0-1e1b-438c-a00b-cfe0cdd0f464@app.fastmail.com>
In-Reply-To: <68eba37e-1bfe-4509-af41-112bb196415c@app.fastmail.com>
References: <d603f372-5f58-4308-aba1-151c35f3aa94@app.fastmail.com>
 <68eba37e-1bfe-4509-af41-112bb196415c@app.fastmail.com>
Subject: Re: [PHP-DEV] RFC: Records
Content-Type: multipart/alternative;
 boundary=293ce24b1d9c49cb9213bb55d1e13f83
From: rob@bottled.codes ("Rob Landers")

--293ce24b1d9c49cb9213bb55d1e13f83
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello Ilija and Larry,

You both touch upon some interesting and similar thoughts, and it may be=
 worth sharing how I arrived here; at least so we have some shared conte=
xt:

Personally, I feel that classes are quite bloated with features and what=
 feature works with what is quite confusing for new developers; I would =
rather see features removed than added to them at this point. This isn't=
 why I chose the "record" keyword or a new syntax, to be clear. However,=
 it was one of many strong reasons as to why I felt it would be an ok de=
viation from "tacking on more features to classes."

One of the main reasons for the alternative creation syntax is because I=
 felt that "new" was misleading at best, and just plain wrong at worst. =
It is also why I chose "&", to make it clear you are not getting "a new =
one" but one that "just happens to exist with the values you asked for."=
 I'd be open to a different keyword or something else entirely. It's jus=
t that "new" is the wrong one for records.

I did explore "data classes" to a degree, and I can see why Ilija create=
d the new "mutating" syntax for their RFC. It gets really weird, really =
fast. Records are the other side of structs, though. They are (nearly li=
terally) arrays with a class entry on them, and thus, essentially, typed=
 structured arrays with behavior. In fact, I was originally going to pit=
ch it as such, but decided it would either stand on its own or not; but =
it is what they were designed to be from the beginning; hence the short =
declaration syntax.

In other words, I see this being used anywhere you'd normally use a stru=
ctured array but want some type safety, without all the boilerplate of c=
lasses or dealing with equality. For example, DTO's, configuration, etc.=
 They solve a different problem than Ilija's structs, which makes more s=
ense for collections, but I see records as being good candidates for val=
ues in those collections.

As I shopped this RFC around to coworkers, old coworkers, other maintain=
ers on the projects I work on, and (nearly) random strangers on the inte=
rnet, it became clear that people liked it and understood them, but want=
ed more power. Things like better custom (de)serialization than what we =
have with readonly classes, custom initializers for computed properties,=
 etc.=20

Furthermore, as I thought about these new features for records, I also t=
hought about how people would use them. They would most likely start wit=
h a simple record (or not), but when changing them, I also thought about=
 the diffs they would create in code reviews. In fact, this is a large r=
eason behind the rules for traditional constructors. Adding a traditiona=
l constructor to an already existing record should look exactly like tha=
t in the diff, without shifting around a bunch of properties.

Eventually, we ended up with the RFC you are reading today.

(To be 100% transparent, some people also thought it was pointless and w=
ondered what was wrong with readonly classes, but I'll come back to that=
).

Now, with that context in mind...

On Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote:
> Plus, having another fixed type creates questions any time a new featu=
re is added.

I think this would happen even if I scoped out some of the RFCs you hint=
ed at. I don't think there is any way around this. Adding new features c=
omplicates future features, and it doesn't matter where you put them. Or=
 rather, it matters, but not as much as you'd think.

For example, my nameof RFC is basically on hiatus until we have pattern =
matching. We simply lack the grammar necessary to do it correctly, and i=
t doesn't seem like the place to define that grammar because then it may=
 pigeonhole pattern matching. I think that is fine, but these are normal=
 things to go through when working on an RFC, in my limited experience.

My point is, we constantly have to make this decision process, and we ju=
st have to 'figure it out' as we go.

On Sun, Nov 17, 2024, at 01:15, Ilija Tovilo wrote:
> I personally do not think immutable data structures are a good
> solution to the problem, and I don't feel like we need another,
> slightly shorter way to do the same thing.

On Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote:
> As Ilija notes, immutable objects are not always the answer.  I like t=
hem, and use them frequently, but they're not always appropriate.  And w=
e already have them with either readonly classes or now private(set) (wh=
ich is close enough to immutable 99.4% of the time)

To be clear, this is another tool in the developer's toolbox and not mea=
nt to replace classes (even readonly classes). They are strictly immutab=
le value objects, which makes sense for numbers, time, custom values (se=
e: the UserId example in the RFC), etc. These aren't as good for generic=
 collections like maps, sets, vectors, etc. or even things like services=
 or controllers. For these types of things, classes (or structs) make mo=
re sense.

Like Ilija mentioned in their email, there are significant performance o=
ptimizations to be had here that are simply not possible using regular (=
readonly) classes. I didn't go into detail as to how it works because it=
 feels like an implementation detail, but I will spend some time distill=
ing this and its consequences, into the RFC, over the coming days. As a =
simple illustration, there can be significant memory usage improvements:

100,000 arrays: https://3v4l.org/Z4CcV
100,000 readonly classes: https://3v4l.org/1vhNp

and what we would expect from records: https://3v4l.org/4nYXG which is o=
n par with the array example.

Naturally, real life won't see that kind of reduction in memory consumpt=
ion (nobody is creating an array of all the same items, most of the time=
), but hopefully it gives you an idea of what can be gained.

On Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote:
> I can see the benefit of an inline constructor.  Kotlin has something =
similar.  But I can see the benefit of it for all classes, even service =
classes, not just records.  (In Kotlin, it's used for service classes al=
l the time.)

I think this would be a good future scope. If people like it, an RFC to =
extend it to regular classes makes sense.

> There's already been an RFC for clone-with that works on any object; i=
t just never made it to a vote.  I could see an argument for an even mor=
e dedicated syntax (eg, eliminate "clone" and just do "$foo with (bar: '=
baz')"), but again, useful on all objects, not just records.

I feel like this is similar to my nameof RFC and doomed from the start. =
Classes are just too featureful to pin down what a "with" actually means=
. The discussion went into depth on this, and nothing definitive came ou=
t of it (IMHO). In a sense, records get a "fresh start" and can define e=
xactly what it means and how it can be used.

> The alternate creation syntax... OK, this one I can't really see a ben=
efit to, and Ilija already noted it may cause conflicts.

And from Ilija:
> A small note: The $test =3D &Test(); syntax is ambiguous, as it's
> already legal. https://3v4l.org/CE5rt

I originally had something about this in the RFC but removed it at the l=
ast minute. I'll add it back! For now, it will live in "open issues" in =
case someone has a better idea. As to the reason for it, I covered it br=
iefly above, but as a reminder, it boils down to my reluctance to use "n=
ew" to get a record. If anyone has any better ideas, I'm open to it.

And again, from Larry:
> Value-based strong equality, in cases where I want that, I also want t=
o be able to control it.  That goes back to Jordan's operator overload R=
FC, and specifying a custom =3D=3D and <=3D>.  I'd rather just have that.

I originally wanted to add operators. For (I hope) obvious reasons, I de=
cided to just wait for them. I think something like records (with value =
semantics built-in) would be much more palatable for people worried abou=
t the "abuse" of operators. I'm just going to steer clear of that topic =
and leave it "undefined" for now--with the expectation that someone (Jor=
dan?) may come along to define operations on objects.

> Value-style passing is the really interesting one, but I want to be ab=
le to use it without being forced into all of the other features here.

I don't think there is much way around it. You either need a special syn=
tax (structs) or immutability (records). For regular classes, there is a=
lways "=3D=3D" if you have control over how they are compared. Sadly, I =
don't think this is possible for regular classes, but I could be wrong.

And... that's a book. I'm really sorry about the length of this email, b=
ut hopefully I've addressed both your questions and concerns as best I c=
an.

Sincerely,

=E2=80=94 Rob
--293ce24b1d9c49cb9213bb55d1e13f83
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>Hello Ilija and=
 Larry,<br></div><div><br style=3D"max-width:100%;height:auto;"></div><d=
iv>You both touch upon some interesting and similar thoughts, and it may=
 be worth sharing how I arrived here; at least so we have some shared co=
ntext:<br></div><div><br></div><div>Personally, I feel that classes are =
quite bloated with features and what feature works with what is quite co=
nfusing for new developers; I would rather see features removed than add=
ed to them at this point. This isn't why I chose the "record" keyword or=
 a new syntax, to be clear. However, it was one of many strong reasons a=
s to why I felt it would be an ok deviation from "tacking on more featur=
es to classes."<br></div><div><br style=3D"max-width:100%;height:auto;">=
</div><div>One of the main reasons for the alternative creation syntax i=
s because I felt that "new" was misleading at best, and just plain wrong=
 at worst. It is also why I chose "&amp;", to make it clear you are not =
getting "a new one" but one that "just happens to exist with the values =
you asked for." I'd be open to a different keyword or something else ent=
irely. It's just that "new" is the wrong one for records.<br style=3D"ma=
x-width:100%;height:auto;"></div><div><br style=3D"max-width:100%;height=
:auto;"></div><div>I did explore "data classes" to a degree, and I can s=
ee why Ilija created the new "mutating" syntax for their RFC. It gets re=
ally weird, really fast. Records are the other side of structs, though. =
They are (nearly literally) arrays with a class entry on them, and thus,=
 essentially, typed structured arrays with behavior. In fact, I was orig=
inally going to pitch it as such, but decided it would either stand on i=
ts own or not; but it is what they were designed to be from the beginnin=
g; hence the short declaration syntax.<br style=3D"max-width:100%;height=
:auto;"></div><div><br style=3D"max-width:100%;height:auto;"></div><div>=
In other words, I see this being used anywhere you'd normally use a stru=
ctured array but want some type safety, without all the boilerplate of c=
lasses or dealing with equality. For example, DTO's, configuration, etc.=
 They solve a different problem than Ilija's structs, which makes more s=
ense for collections, but I see records as being good candidates for val=
ues in those collections.<br></div><div><br></div><div>As I shopped this=
 RFC around to coworkers, old coworkers, other maintainers on the projec=
ts I work on, and (nearly) random strangers on the internet, it became c=
lear that people liked it and understood them, but wanted more power. Th=
ings like better custom (de)serialization than what we have with readonl=
y classes, custom initializers for computed properties, etc. <br></div><=
div><br></div><div>Furthermore, as I thought about these new features fo=
r records, I also thought about how people would use them. They would mo=
st likely start with a simple record (or not), but when changing them, I=
 also thought about the diffs they would create in code reviews. In fact=
, this is a large reason behind the rules for traditional constructors. =
Adding a traditional constructor to an already existing record should lo=
ok exactly like that in the diff, without shifting around a bunch of pro=
perties.<br></div><div><br></div><div>Eventually, we ended up with the R=
FC you are reading today.<br></div><div><br></div><div>(To be 100% trans=
parent, some people also thought it was pointless and wondered what was =
wrong with readonly classes, but I'll come back to that).<br></div><div>=
<br></div><div>Now, with that context in mind...<br></div><div><br></div=
><div>On Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote:<br></div><bl=
ockquote type=3D"cite"><div>Plus, having another fixed type creates ques=
tions any time a new feature is added.<br></div></blockquote><div><br></=
div><div>I think this would happen even if I scoped out some of the RFCs=
 you hinted at. I don't think there is any way around this. Adding new f=
eatures complicates future features, and it doesn't matter where you put=
 them. Or rather, it matters, but not as much as you'd think.<br></div><=
div><br></div><div>For example, my nameof RFC is basically on hiatus unt=
il we have pattern matching. We simply lack the grammar necessary to do =
it correctly, and it doesn't seem like the place to define that grammar =
because then it may pigeonhole pattern matching. I think that is fine, b=
ut these are normal things to go through when working on an RFC, in my l=
imited experience.<br></div><div><br></div><div>My point is, we constant=
ly have to make this decision process, and we just have to 'figure it ou=
t' as we go.</div><div><br></div><div>On Sun, Nov 17, 2024, at 01:15, Il=
ija Tovilo wrote:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D"=
"><div>I personally do not think immutable data structures are a good<br=
></div><div>solution to the problem, and I don't feel like we need anoth=
er,<br></div><div>slightly shorter way to do the same thing.<br></div></=
blockquote><div><br></div><div>On Sun, Nov 17, 2024, at 08:21, Larry Gar=
field wrote:<br></div><blockquote type=3D"cite"><div>As Ilija notes, imm=
utable objects are not always the answer.&nbsp; I like them, and use the=
m frequently, but they're not always appropriate.&nbsp; And we already h=
ave them with either readonly classes or now private(set) (which is clos=
e enough to immutable 99.4% of the time)<br></div></blockquote><div><br>=
</div><div>To be clear, this is another tool in the developer's toolbox =
and not meant to replace classes (even readonly classes). They are stric=
tly immutable value objects, which makes sense for numbers, time, custom=
 values (see: the UserId example in the RFC), etc. These aren't as good =
for generic collections like maps, sets, vectors, etc. or even things li=
ke services or controllers. For these types of things, classes (or struc=
ts) make more sense.<br></div><div><br></div><div>Like&nbsp;Ilija mentio=
ned in their email, there are significant performance optimizations to b=
e had here that are simply not possible using regular (readonly) classes=
. I didn't go into detail as to how it works because it feels like an im=
plementation detail, but I will spend some time distilling this and its =
consequences, into the RFC, over the coming days. As a simple illustrati=
on, there can be significant memory usage improvements:<br></div><div><b=
r></div><div>100,000 arrays:&nbsp;<a href=3D"https://3v4l.org/Z4CcV">htt=
ps://3v4l.org/Z4CcV</a><br></div><div>100,000 readonly classes:&nbsp;<a =
href=3D"https://3v4l.org/1vhNp">https://3v4l.org/1vhNp</a><br></div><div=
><br></div><div>and what we would expect from records:&nbsp;<a href=3D"h=
ttps://3v4l.org/4nYXG">https://3v4l.org/4nYXG</a>&nbsp;which is on par w=
ith the array example.<br></div><div><br></div><div>Naturally, real life=
 won't see that kind of reduction in memory consumption (nobody is creat=
ing an array of all the same items, most of the time), but hopefully it =
gives you an idea of what can be gained.<br></div><div><br></div><div>On=
 Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote:<br></div><blockquote=
 type=3D"cite"><div>I can see the benefit of an inline constructor.&nbsp=
; Kotlin has something similar.&nbsp; But I can see the benefit of it fo=
r all classes, even service classes, not just records.&nbsp; (In Kotlin,=
 it's used for service classes all the time.)<br></div></blockquote><div=
><br></div><div>I think this would be a good future scope. If people lik=
e it, an RFC to extend it to regular classes makes sense.<br></div><div>=
<br></div><blockquote type=3D"cite"><div>There's already been an RFC for=
 clone-with that works on any object; it just never made it to a vote.&n=
bsp; I could see an argument for an even more dedicated syntax (eg, elim=
inate "clone" and just do "$foo with (bar: 'baz')"), but again, useful o=
n all objects, not just records.<br></div></blockquote><div><br></div><d=
iv>I feel like this is similar to my nameof RFC and doomed from the star=
t. Classes are just too featureful to pin down what a "with" actually me=
ans. The discussion went into depth on this, and nothing definitive came=
 out of it (IMHO). In a sense, records get a "fresh start" and can defin=
e exactly what it means and how it can be used.<br></div><div><br></div>=
<blockquote type=3D"cite"><div>The alternate creation syntax... OK, this=
 one I can't really see a benefit to, and Ilija already noted it may cau=
se conflicts.<br></div></blockquote><div><br></div><div>And from&nbsp;Il=
ija:<br></div><blockquote type=3D"cite"><div>A small note: The $test =3D=
 &amp;Test(); syntax is ambiguous, as it's<br></div><div>already legal. =
<a href=3D"https://3v4l.org/CE5rt">https://3v4l.org/CE5rt</a><br></div><=
/blockquote><div><br></div><div>I originally had something about this in=
 the RFC but removed it at the last minute. I'll add it back! For now, i=
t will live in "open issues" in case someone has a better idea. As to th=
e reason for it, I covered it briefly above, but as a reminder, it boils=
 down to my reluctance to use "new" to get a record. If anyone has any b=
etter ideas, I'm open to it.<br></div><div><br></div><div>And again, fro=
m Larry:<br></div><blockquote type=3D"cite"><div>Value-based strong equa=
lity, in cases where I want that, I also want to be able to control it.&=
nbsp; That goes back to Jordan's operator overload RFC, and specifying a=
 custom =3D=3D and &lt;=3D&gt;.&nbsp; I'd rather just have that.<br></di=
v></blockquote><div><br></div><div>I originally wanted to add operators.=
 For (I hope) obvious reasons, I decided to just wait for them. I think =
something like records (with value semantics built-in) would be much mor=
e palatable for people worried about the "abuse" of operators. I'm just =
going to steer clear of that topic and leave it "undefined" for now--wit=
h the expectation that someone (Jordan?) may come along to define operat=
ions on objects.<br></div><div><br></div><blockquote type=3D"cite"><div>=
Value-style passing is the really interesting one, but I want to be able=
 to use it without being forced into all of the other features here.<br>=
</div></blockquote><div><br></div><div>I don't think there is much way a=
round it. You either need a special syntax (structs) or immutability (re=
cords). For regular classes, there is always "=3D=3D" if you have contro=
l over how they are compared. Sadly, I don't think this is possible for =
regular classes, but I could be wrong.<br></div><div><br></div><div>And.=
.. that's a book. I'm really sorry about the length of this email, but h=
opefully I've addressed both your questions and concerns as best I can.<=
br></div><div><br></div><div>Sincerely,<br></div><div><br style=3D"max-w=
idth:100%;height:auto;"></div><div id=3D"sig121229152">=E2=80=94 Rob<br>=
</div></body></html>
--293ce24b1d9c49cb9213bb55d1e13f83--