Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122892
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-ID: <d7e8ff3b-2bec-4e52-8d0f-59e39367df6b@app.fastmail.com>
In-Reply-To: 
 <CA+hqhpc65J8gJLNTGMrhcAWQ2_+vqp9XmG2dKNQxTLP0tAjwSg@mail.gmail.com>
References: 
 <CAPyj-LA7kJLdz3Pzbxr6x-7v2YV8n06pwxs6QoVe3CGgx-_GGA@mail.gmail.com>
 <1a4a44c5-d4f5-40ca-b3dc-13d64c2b4425@app.fastmail.com>
 <CAPyj-LBS5iUEX_Y9gqGL_vsFjTgZCsDT3YUGQgZw43oFVE2XiA@mail.gmail.com>
 <CA+hqhpc65J8gJLNTGMrhcAWQ2_+vqp9XmG2dKNQxTLP0tAjwSg@mail.gmail.com>
Date: Tue, 02 Apr 2024 21:37:50 +0200
To: "Bruce Weirdan" <weirdan@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
Content-Type: multipart/alternative;
 boundary=a711b7d7c03345e68cb0006cad3d5805
From: rob@bottled.codes ("Rob Landers")

--a711b7d7c03345e68cb0006cad3d5805
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024, at 20:51, Bruce Weirdan wrote:
> On Tue, Apr 2, 2024 at 8:05=E2=80=AFPM Ilija Tovilo <tovilo.ilija@gmai=
l.com> wrote:
>=20
> > Equality for data objects is based on data, rather than the object
> > handle.
>=20
> I believe equality should always consider the type of the object.
>=20
> ```php
> new Problem(size:'big') =3D=3D=3D new Universe(size:'big')
> && new Problem(size:'big') =3D=3D=3D new Shoe(size:'big');
> ```
>=20
> If the above can ever be true then I'm not sure how big is the problem
> (but probably very big).
> Also see the examples of non-comparable ids - `new CompanyId(1)`
> should not be equal to `new PersonId(1)`
>=20
> And I'd find it very confusing if the following crashed
>=20
> ```php
> function f(Universe $_u): void {}
> $universe =3D new Universe(size:'big');
> $shoe =3D new Shoe(size:'big);
>=20
> if ($shoe =3D=3D=3D $universe) {
>    f($shoe); // shoe is *identical* to the universe, so it should be
> accepted wherever the universe is
> }
> ```
>=20
> --=20
>   Best regards,
>       Bruce Weirdan                                     mailto:weirdan=
@gmail.com
>=20

I'd love to see it so that equality was more like =3D=3D for regular obj=
ects. If the type matches and the data matches, it's true. It'd be reall=
y helpful to be able to downcast types though. Such as in my user id exa=
mple I gave earlier. Once it reaches a certain point in the code, it doe=
sn't matter that it was once a UserId, it just matters that it is curren=
tly an Id.

Now that I think about it, decoration might be better than inheritance h=
ere and inheritance might make more sense to be banned. In other words, =
this might be just as simple and easy to use:

data class Id {
  public function __construct(public string $id) {}
}

data class UserId {
  public function __construct(public Id $id) {}
}

Though it would be really interesting to use them as "traits" for each o=
ther to say "this data class can be converted to another type, but infor=
mation will be lost" where they are 100% separate types but can be "cast=
" to specified types.

// "use" has all the same rules as extends, but,
// UserId is not an Id; it can be converted to an Id
data class UserId use Id {
  public function __construct(public string $id, public string $name) {}
}

$user =3D new UserId('123', 'rob');

$id =3D (Id) $user;

$user !=3D=3D $id =3D=3D=3D true;

$id is 100% Id and lost all its "userness." Hmm. Interesting indeed. Pro=
bably not practical, but interesting.

=E2=80=94 Rob
--a711b7d7c03345e68cb0006cad3d5805
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>On Tue, Apr 2, =
2024, at 20:51, Bruce Weirdan wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>On Tue, Apr 2, 2024 at 8:05=E2=80=AFPM Ilija T=
ovilo &lt;<a href=3D"mailto:tovilo.ilija@gmail.com">tovilo.ilija@gmail.c=
om</a>&gt; wrote:<br></div><div><br></div><div>&gt; Equality for data ob=
jects is based on data, rather than the object<br></div><div>&gt; handle=
.<br></div><div><br></div><div>I believe equality should always consider=
 the type of the object.<br></div><div><br></div><div>```php<br></div><d=
iv>new Problem(size:'big') =3D=3D=3D new Universe(size:'big')<br></div><=
div>&amp;&amp; new Problem(size:'big') =3D=3D=3D new Shoe(size:'big');<b=
r></div><div>```<br></div><div><br></div><div>If the above can ever be t=
rue then I'm not sure how big is the problem<br></div><div>(but probably=
 very big).<br></div><div>Also see the examples of non-comparable ids - =
`new CompanyId(1)`<br></div><div>should not be equal to `new PersonId(1)=
`<br></div><div><br></div><div>And I'd find it very confusing if the fol=
lowing crashed<br></div><div><br></div><div>```php<br></div><div>functio=
n f(Universe $_u): void {}<br></div><div>$universe =3D new Universe(size=
:'big');<br></div><div>$shoe =3D new Shoe(size:'big);<br></div><div><br>=
</div><div>if ($shoe =3D=3D=3D $universe) {<br></div><div>&nbsp;&nbsp; f=
($shoe); // shoe is *identical* to the universe, so it should be<br></di=
v><div>accepted wherever the universe is<br></div><div>}<br></div><div>`=
``<br></div><div><br></div><div>--&nbsp;<br></div><div>&nbsp; Best regar=
ds,<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bruce Weirdan&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailto:<a=
 href=3D"mailto:weirdan@gmail.com">weirdan@gmail.com</a><br></div><div><=
br></div></blockquote><div><br></div><div>I'd love to see it so that equ=
ality was more like =3D=3D for regular objects. If the type matches and =
the data matches, it's true. It'd be really helpful to be able to downca=
st types though. Such as in my user id example I gave earlier. Once it r=
eaches a certain point in the code, it doesn't matter that it was once a=
 UserId, it just matters that it is currently an Id.<br></div><div><br><=
/div><div>Now that I think about it, decoration might be better than inh=
eritance here and inheritance might make more sense to be banned. In oth=
er words, this might be just as simple and easy to use:<br></div><div><b=
r></div><div>data class Id {<br></div><div>&nbsp; public function __cons=
truct(public string $id) {}<br></div><div>}<br></div><div><br></div><div=
>data class UserId {<br></div><div>&nbsp; public function __construct(pu=
blic Id $id) {}<br></div><div>}<br></div><div><br></div><div>Though it w=
ould be really interesting to use them as "traits" for each other to say=
 "this data class can be converted to another type, but information will=
 be lost" where they are 100% separate types but can be "cast" to specif=
ied types.<br></div><div><br></div><div>// "use" has all the same rules =
as extends, but,<br></div><div>// UserId is not an Id; it can be convert=
ed to an Id<br></div><div>data class UserId use Id {<br></div><div>&nbsp=
; public function __construct(public string $id, public string $name) {}=
</div><div>}<br></div><div><br></div><div>$user =3D new UserId('123', 'r=
ob');<br></div><div><br></div><div>$id =3D (Id) $user;<br></div><div><br=
></div><div>$user !=3D=3D $id =3D=3D=3D true;<br></div><div><br></div><d=
iv>$id is 100% Id and lost all its "userness." Hmm. Interesting indeed. =
Probably not practical, but interesting.<br></div><div><br></div><div id=
=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--a711b7d7c03345e68cb0006cad3d5805--