Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125057
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 20 Aug 2024 01:37:49 +0200
To: internals@lists.php.net
Message-ID: <cf9d6236-9027-4eac-b785-4bfd38b9990f@app.fastmail.com>
In-Reply-To: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
Subject: Re: [PHP-DEV] State of Generics and Collections
Content-Type: multipart/alternative;
 boundary=647d3cdb0a4f49628fec2e627e45291e
From: rob@bottled.codes ("Rob Landers")

--647d3cdb0a4f49628fec2e627e45291e
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 19, 2024, at 19:08, Derick Rethans wrote:
> Hi!
>=20
> Arnaud, Larry, and I have been working on an article describing the=20
> state of generics and collections, and related "experiments".
>=20
> You can find this article on the PHP Foundation's Blog:
> https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collec=
tions/
>=20
> cheers,
> Derick
>=20

As an experiment, awhile ago, I went a different route for reified gener=
ics by 'hacking' type aliases (which I was also experimenting with). Suc=
h that a generic becomes compiled into a concrete implementation with a =
dangling type alias:

class Box<T> {
  function __construct(T $thing) {}
}

is essentially compiled to

class Box {
  use alias __Box_T =3D> ???;

  function __construct(__Box_T $thing) {}
}

This just gets a T type alias (empty-ish, with a mangled name) that gets=
 filled in during runtime (every instance gets its own type alias table,=
 and uses that along with the file alias table). There shouldn't be any =
performance impact this way (or at least, as bad as using type aliases, =
in general; which is also an oft-requested feature).

Thus, when you create a new Box<int> it just fills in that type alias fo=
r T as int. Nesting still works too Box<Box<int>> is just an int type al=
ias on the inner Box and the outer Box alias is just Box. Type-checking =
basically works just like it does today (IIRC, Box<int> literally got st=
ored as "Box<int>" for fast checking), and reflection just looks up the =
type aliases and unmangles them -- though I know for certain I never fin=
ished reflection and got bogged down in GC shenanigans.

There were probably some serious cons in that approach, but I ran out of=
 free time to investigate. If you are doing experiments, it is probably =
worth looking into.

FYI though, people seemed really turned off by file-level type aliases (=
at least exposed to user-land, so I never actually pursued it).

=E2=80=94 Rob






--647d3cdb0a4f49628fec2e627e45291e
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}=0Ap.MsoNormal,p.MsoNoSpacing{margin:0}=0A=
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Mon, Au=
g 19, 2024, at 19:08, Derick Rethans wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>Hi!<br></div><div><br></div><div>Arnaud=
, Larry, and I have been working on an article describing the&nbsp;<br><=
/div><div>state of generics and collections, and related "experiments".<=
br></div><div><br></div><div>You can find this article on the PHP Founda=
tion's Blog:<br></div><div><a href=3D"https://thephp.foundation/blog/202=
4/08/19/state-of-generics-and-collections/">https://thephp.foundation/bl=
og/2024/08/19/state-of-generics-and-collections/</a><br></div><div><br><=
/div><div>cheers,<br></div><div>Derick<br></div><div><br></div></blockqu=
ote><div><br></div><div><div>As an experiment, awhile ago, I went a diff=
erent route for reified generics by 'hacking' type aliases (which I was =
also experimenting with). Such that a generic becomes compiled into a co=
ncrete implementation with a dangling type alias:<br></div><div><br></di=
v><div>class Box&lt;T&gt; {<br></div><div>&nbsp; function __construct(T =
$thing) {}<br></div><div>}<br></div><div><br></div><div>is essentially c=
ompiled to<br></div><div><br></div><div>class Box {<br></div><div>&nbsp;=
 use alias __Box_T =3D&gt; ???;<br></div><div><br></div><div>&nbsp; func=
tion __construct(__Box_T $thing) {}<br></div><div>}<br></div><div><br></=
div><div>This just gets a T type alias (empty-ish, with a mangled name) =
that gets filled in during runtime (every instance gets its own type ali=
as table, and uses that along with the file alias table). There shouldn'=
t be any performance impact this way (or at least, as bad as using type =
aliases, in general; which is also an oft-requested feature).<br></div><=
div><br></div><div>Thus, when you create a new Box&lt;int&gt; it just fi=
lls in that type alias for T as int. Nesting still works too Box&lt;Box&=
lt;int&gt;&gt; is just an int type alias on the inner Box and the outer =
Box alias is just Box. Type-checking basically works just like it does t=
oday (IIRC, Box&lt;int&gt; literally got stored as "Box&lt;int&gt;" for =
fast checking), and reflection just looks up the type aliases and unmang=
les them -- though I know for certain I never finished reflection and go=
t bogged down in GC shenanigans.<br></div><div><br></div><div>There were=
 probably some serious cons in that approach, but I ran out of free time=
 to investigate. If you are doing experiments, it is probably worth look=
ing into.</div><div><br></div><div>FYI though, people seemed really turn=
ed off by file-level type aliases (at least exposed to user-land, so I n=
ever actually pursued it).<br></div><div><br></div><div>=E2=80=94 Rob<br=
></div><div><br></div><div><br></div><div><br></div><div><br></div><div>=
<br></div></div><div><br></div></body></html>
--647d3cdb0a4f49628fec2e627e45291e--