Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126723
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 11 Mar 2025 23:16:47 +0100
To: internals@lists.php.net
Message-ID: <99276fb0-548b-42b4-8ba1-5c96e3052640@app.fastmail.com>
In-Reply-To: 
 <CALaXqqTNv+EBLUnkQSWU3ka0U6n5Fot0ywm1+XRCU5ttrAGe+w@mail.gmail.com>
References: 
 <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
 <934418CE-579E-4621-BB7A-5332B87C27B2@zort.net>
 <CALaXqqTNv+EBLUnkQSWU3ka0U6n5Fot0ywm1+XRCU5ttrAGe+w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Never parameters
Content-Type: multipart/alternative;
 boundary=d3d6ff414cd74e29b5b65585236e723b
From: rob@bottled.codes ("Rob Landers")

--d3d6ff414cd74e29b5b65585236e723b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=20
>=20
>> I would also personally prefer associated types: ... This at least le=
ts you ensure the "other point" is the same type in both functions, thou=
gh personally, I'd rather just have generics.
>=20
> I'd also like to have generics, but that isn't something I can impleme=
nt myself. Associated types would be interesting, but I don't think that=
 associated types would remove the entire use-case for `never` parameter=
s, just perhaps the specific example of BackedEnum.
>=20
> ----
> - Daniel

Heh, this is the long game I am playing with inner classes: https://exte=
rnals.io/message/125049#125057

If inner classes can be implemented, then we are just a short hop from b=
eing able to implement generics with a similar approach to what I outlin=
ed in that thread. Granted, I'm making some major changes to the RFC at =
the moment and the implementation -- based on feedback, so it'll be a fe=
w days before that is finished.

An inner class view of generics (as opposed to the type aliasing view in=
 that thread) looks something like this:

// Box<T>
class Box {
  public class T {}

  // store(T $item)
  public function store(static:>T $item) {}
}

// new Box<ItemType>()
$box =3D new class() extends Box {
  public class ItemType as T {}
};

-Ish. Note that the example won=E2=80=99t actually work; but it illustra=
tes how the engine could implement it if there were inner/nested types.

So, assuming this new implementation I=E2=80=99ve been working on is waa=
ay better than the old one (I think it is), and the RFC is accepted; we =
may be closer to generics than you thought. Or maybe there is someone ou=
t there with a whole different way of doing it that is even better=E2=80=
=A6 This is the approach I'm chasing though.

=E2=80=94 Rob
--d3d6ff414cd74e29b5b65585236e723b
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}</=
style></head><body><div>&nbsp;<br></div><blockquote type=3D"cite" id=3D"=
qt" style=3D""><div dir=3D"ltr"><div class=3D"qt-gmail_quote qt-gmail_qu=
ote_container"><div><br></div><blockquote class=3D"qt-gmail_quote" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
 204, 204);padding-left:1ex;">I would also personally prefer associated =
types: ...&nbsp;This at least lets you ensure the "other point" is the s=
ame type in both functions, though personally, I'd rather just have gene=
rics.<br></blockquote><div><br></div><div>I'd also like to have generics=
, but that isn't something I can implement myself. Associated types woul=
d be interesting, but I don't think that associated types would remove t=
he entire use-case for `never` parameters, just perhaps the specific exa=
mple of BackedEnum.<br></div><div><br></div><div>----<br></div><div>- Da=
niel<br></div></div></div></blockquote><div><br></div><div>Heh, this is =
the long game I am playing with inner classes:&nbsp;<a href=3D"https://e=
xternals.io/message/125049#125057">https://externals.io/message/125049#1=
25057</a><br></div><div><br></div><div>If inner classes can be implement=
ed, then we are just a short hop from being able to implement generics w=
ith a similar approach to what I outlined in that thread. Granted, I'm m=
aking some major changes to the RFC at the moment and the implementation=
 -- based on feedback, so it'll be a few days before that is finished.<b=
r></div><div><br></div><div>An inner class view of generics (as opposed =
to the type aliasing view in that thread) looks something like this:<br>=
</div><div><br></div><div>// Box&lt;T&gt;<br></div><div>class Box {<br><=
/div><div>&nbsp; public class T {}<br></div><div><br></div><div>&nbsp; /=
/ store(T $item)<br></div><div>&nbsp; public function store(static:&gt;T=
 $item) {}<br></div><div>}<br></div><div><br></div><div>// new Box&lt;It=
emType&gt;()<br></div><div>$box =3D new class() extends Box {<br></div><=
div>&nbsp; public class ItemType as T {}<br></div><div>};<br></div><div>=
<br></div><div>-Ish. Note that the example won=E2=80=99t actually work; =
but it illustrates how the engine could implement it if there were inner=
/nested types.<br></div><div><br></div><div>So, assuming this new implem=
entation I=E2=80=99ve been working on is waaay better than the old one (=
I think it is), and the RFC is accepted; we may be closer to generics th=
an you thought. Or maybe there is someone out there with a whole differe=
nt way of doing it that is even better=E2=80=A6 This is the approach I'm=
 chasing though.<br></div><div><br></div><div id=3D"sig121229152">=E2=80=
=94 Rob<br></div></body></html>
--d3d6ff414cd74e29b5b65585236e723b--