Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125063
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 20 Aug 2024 09:48:17 +0200
To: "Bob Weinand" <bobwei9@hotmail.com>,
 "Larry Garfield" <larry@garfieldtech.com>,
 "php internals" <internals@lists.php.net>
Message-ID: <ac473462-5619-44a0-b98a-072fc77232f5@app.fastmail.com>
In-Reply-To: 
 <AM8P250MB0170C4C1868D33AB0CEE2550E28D2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <AM8P250MB01706B1541E1283F4065B94AE28C2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <d5fa624c-0c0f-4fed-adea-4f7e0e3a6728@app.fastmail.com>
 <AM8P250MB0170C4C1868D33AB0CEE2550E28D2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Subject: Re: [PHP-DEV] State of Generics and Collections
Content-Type: multipart/alternative;
 boundary=690eb8d82314400b8e278950a1440d7c
From: rob@bottled.codes ("Rob Landers")

--690eb8d82314400b8e278950a1440d7c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2024, at 03:53, Bob Weinand wrote:
> On 20.8.2024 03:31:05, Larry Garfield wrote:
>> On Mon, Aug 19, 2024, at 5:16 PM, Bob Weinand wrote:
>>=20
>>=20
>>> Regarding the Collections PR, I personally really don't like it:
>>>=20
>>>  =E2=80=A2 It implements something which would be trivial if we had =
reified=20
>>> generics. If this ever gets merged, and generics happen later, it wo=
uld=20
>>> be probably outdated and quirkiness the language has to carry around.
>>>  =E2=80=A2 It's not powerful. But rather a quite limited implementat=
ion. No=20
>>> overrides of the built-in methods possible. No custom operations ("I=20
>>> want a dict where a specific property on the key is the actual uniqu=
e=20
>>> key", "I want a custom callback be executed for each modification").=20
>>> It's okay as a PoC, but far from a complete enough implementation.
>>>=20
>> I think we weren't that clear on that section, then.  The intent is t=
hat dedicated collection classes are, well, classes.  They can contain a=
dditional methods, and probably can override the parent methods; though =
the latter may have some trickiness if trying to access the internal dat=
a structure, which may or may not look array-ish.  (That's why it's just=
 a PoC and we're asking for feedback if it's worth trying to investigate=
 further.)
> I assumed so, as said "okay as a PoC" :-)
>>>  =E2=80=A2 It's a very specialized structure/syntax, not extensible =
for=20
>>> userland at all. Some functionality like generic traits, where you'd=20
>>> actually monomorphize the contained methods would be much more=20
>>> flexible. E.g. class Articles { use Sequence<Article>; }. Much less=20
>>> specialized syntax, much more extensible. And generic traits would b=
e=20
>>> doable, regardless of the rest of the generics investigation.
>>> In fact, generic traits (essentially statically replacing the generi=
c=20
>>> arguments at link-time) would be an useful feature which would remai=
n=20
>>> useful even if we had fully reified generics.
>>> I recognize that some functionality will need support of internal=20
>>> zend_object_handlers. But that's not a blocker, we might provide som=
e=20
>>> default internal traits with PHP, enabling the internal class handle=
rs.
>>> So to summarize, I would not continue on that path, but really inves=
t=20
>>> into monomorphizable generic traits instead.
>>>=20
>> Interesting.  I have no idea why Arnaud has mainly been investigating=
 reified generics rather than monomorphized, but a monomorphized trait h=
as potential, I suppose.  That naturally leads to the question of whethe=
r monomorphized interfaces would be possible, and I have no idea there. =
 (I still hold out hope that Levi will take another swing at interface-d=
efault-methods.)
>>=20
>> Though this still wouldn't be a path to full generics, as you couldn'=
t declare the inner type of an object at creation time, only code time. =
 Still, it sounds like an area worth considering.
>>=20
>> --Larry Garfield
> Nikita did the investigation into monomorphized generics a long time a=
go (https://github.com/PHPGenerics/php-generics-rfc/issues/44). So it wa=
s mostly concluded that reified generics would be the way to go. The pri=
mary issue Arnauld is currently investigating, is propagation of generic=
 information via runtime behaviour, inference etc.
>=20
> It would be solving large amounts of problems if you'd have to fully s=
pecify the specific instance of a generic every time you instantiate one=
. But PHP is at heart a dynamic language where typing is generally opt-i=
n (also when constructing new objects of generic classes for example). A=
nd we want to avoid "new List<Entry<Foo<Something>, WeakReference<GodObj=
ect>>>()"-style nesting where not necessary.
>=20

I generally follow the philosophy:
 1. get it working
 2. get it working well
 3. get it working fast
And inference seems like a type (2) task. In other words, I think people=
 would be fine with generics, even if they had to type it out every sing=
le time. At least for a start. From there, you'd have multiple people ab=
le to tackle the inference part, proposing RFCs to make it happen, etc. =
vs. now where basically only one person on the planet can attempt to tac=
kle a very complex problem that doesn't exist yet. That isn't to say it =
isn't useful research, because you want to write things in such a way th=
at you can implement inference when you get to (2), but an actual implem=
entation shouldn't be sought out yet, just understanding the problem and=
 solution space is likely enough to do (1) while taking into account (2)=
 -- such as choosing algorithms, op-codes, data structures, etc.

For a feature like this, perfect is very much the enemy of good.

> "Monomorphization of interfaces" does not really make a lot of sense a=
s a concept. Ultimately in an interface, all you do is providing informa=
tion for classes to type check against, which happens at link time, once=
. (Unless you mean interface-default-methods, but that would just be an =
implicitly implemented trait implementation wise, really.)
>=20

Why doesn't it make sense?

interface Id<T> {
  public T $id {
    get =3D> $this->id; // pretty sure this is the wrong syntax?
  }

  public function getId(): T;
  public function setId(T $id): void;
}

class StringId implements Id<string> { /* ... */ }
class IntId implements Id<int> { /* ... */ }

For codebases (like the one I work with every day) identifiers may be a =
string or int and right now, that interface can't exist.

> But sure, generic interfaces and monomorphized generic traits are perf=
ectly implementable today. In fact, I'd definitely suggest we'd start ou=
t by implementing these, orthogonally from actual class generics.
>=20
>=20
>=20
> Bob
>=20
>=20
>=20

=E2=80=94 Rob
--690eb8d82314400b8e278950a1440d7c
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><br></div><div>=
<br></div><div>On Tue, Aug 20, 2024, at 03:53, Bob Weinand wrote:<br></d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div class=3D"qt-moz-c=
ite-prefix">On 20.8.2024 03:31:05, Larry Garfield=0A      wrote:<br></di=
v><blockquote type=3D"cite" cite=3D"mid:d5fa624c-0c0f-4fed-adea-4f7e0e3a=
6728@app.fastmail.com"><pre class=3D"qt-moz-quote-pre">On Mon, Aug 19, 2=
024, at 5:16 PM, Bob Weinand wrote:=0A=0A<br></pre><blockquote type=3D"c=
ite"><pre class=3D"qt-moz-quote-pre">Regarding the Collections PR, I per=
sonally really don't like it:=0A=0A =E2=80=A2 It implements something wh=
ich would be trivial if we had reified=20=0Agenerics. If this ever gets =
merged, and generics happen later, it would=20=0Abe probably outdated an=
d quirkiness the language has to carry around.=0A =E2=80=A2 It's not pow=
erful. But rather a quite limited implementation. No=20=0Aoverrides of t=
he built-in methods possible. No custom operations ("I=20=0Awant a dict =
where a specific property on the key is the actual unique=20=0Akey", "I =
want a custom callback be executed for each modification").=20=0AIt's ok=
ay as a PoC, but far from a complete enough implementation.=0A<br></pre>=
</blockquote><pre class=3D"qt-moz-quote-pre">I think we weren't that cle=
ar on that section, then.  The intent is that dedicated collection class=
es are, well, classes.  They can contain additional methods, and probabl=
y can override the parent methods; though the latter may have some trick=
iness if trying to access the internal data structure, which may or may =
not look array-ish.  (That's why it's just a PoC and we're asking for fe=
edback if it's worth trying to investigate further.)<br></pre></blockquo=
te><div><span style=3D"text-wrap:wrap;">I assumed so, as said "okay as a=
 PoC" :-)</span><br></div><blockquote type=3D"cite" cite=3D"mid:d5fa624c=
-0c0f-4fed-adea-4f7e0e3a6728@app.fastmail.com"><blockquote type=3D"cite"=
><pre class=3D"qt-moz-quote-pre"> =E2=80=A2 It's a very specialized stru=
cture/syntax, not extensible for=20=0Auserland at all. Some functionalit=
y like generic traits, where you'd=20=0Aactually monomorphize the contai=
ned methods would be much more=20=0Aflexible. E.g. class Articles { use =
Sequence&lt;Article&gt;; }. Much less=20=0Aspecialized syntax, much more=
 extensible. And generic traits would be=20=0Adoable, regardless of the =
rest of the generics investigation.=0AIn fact, generic traits (essential=
ly statically replacing the generic=20=0Aarguments at link-time) would b=
e an useful feature which would remain=20=0Auseful even if we had fully =
reified generics.=0AI recognize that some functionality will need suppor=
t of internal=20=0Azend_object_handlers. But that's not a blocker, we mi=
ght provide some=20=0Adefault internal traits with PHP, enabling the int=
ernal class handlers.=0ASo to summarize, I would not continue on that pa=
th, but really invest=20=0Ainto monomorphizable generic traits instead.=0A=
<br></pre></blockquote><pre class=3D"qt-moz-quote-pre">Interesting.  I h=
ave no idea why Arnaud has mainly been investigating reified generics ra=
ther than monomorphized, but a monomorphized trait has potential, I supp=
ose.  That naturally leads to the question of whether monomorphized inte=
rfaces would be possible, and I have no idea there.  (I still hold out h=
ope that Levi will take another swing at interface-default-methods.)=0A=0A=
Though this still wouldn't be a path to full generics, as you couldn't d=
eclare the inner type of an object at creation time, only code time.  St=
ill, it sounds like an area worth considering.=0A=0A--Larry Garfield<br>=
</pre></blockquote><p>Nikita did the investigation into monomorphized ge=
nerics a lon<span style=3D"text-wrap:wrap;">g time ago (<a class=3D"qt-m=
oz-txt-link-freetext" href=3D"https://github.com/PHPGenerics/php-generic=
s-rfc/issues/44">https://github.com/PHPGenerics/php-generics-rfc/issues/=
44</a>). So it was mostly concluded that reified generics would be the w=
ay to go. The primary issue Arnauld is currently investigating, is propa=
gation of generic information via runtime behaviour, inference etc.</spa=
n><br></p><p><span style=3D"text-wrap:wrap;">It would be solving large a=
mounts of problems if you'd have to fully specify the specific instance =
of a generic every time you instantiate one. But PHP is at heart a dynam=
ic language where typing is generally opt-in (also when constructing new=
 objects of generic classes for example). And we want to avoid "new List=
&lt;Entry&lt;Foo&lt;Something&gt;, WeakReference&lt;GodObject&gt;&gt;&gt=
;()"-style nesting where not necessary.</span><br></p></blockquote><div>=
<br></div><div>I generally follow the philosophy:<br></div><ol><li>get i=
t working<br></li><li>get it working well<br></li><li>get it working fas=
t<br></li></ol><div>And inference seems like a type (2) task. In other w=
ords, I think people would be fine with generics, even if they had to ty=
pe it out every single time. At least for a start. From there, you'd hav=
e multiple people able to tackle the inference part, proposing RFCs to m=
ake it happen, etc. vs. now where basically only one person on the plane=
t can attempt to tackle a very complex problem that doesn't exist yet. T=
hat isn't to say it isn't useful research, because you want to write thi=
ngs in such a way that you can implement inference when you get to (2), =
but an actual implementation shouldn't be sought out yet, just understan=
ding the problem and solution space is likely enough to do (1) while tak=
ing into account (2) -- such as choosing algorithms, op-codes, data stru=
ctures, etc.<br></div><div><br></div><div>For a feature like this, perfe=
ct is very much the enemy of good.</div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><p><span style=3D"text-wrap:wrap;">"Monomorp=
hization of interfaces" does not really make a lot of sense as a concept=
. Ultimately in an interface, all you do is providing information for cl=
asses to type check against, which happens at link time, once. (Unless y=
ou mean interface-default-methods, but that would just be an implicitly =
implemented trait implementation wise, really.)</span><br></p></blockquo=
te><div><br></div><div>Why doesn't it make sense?<br></div><div><br></di=
v><div>interface Id&lt;T&gt; {<br></div><div>&nbsp; public T $id {<br></=
div><div>&nbsp; &nbsp; get =3D&gt; $this-&gt;id; // pretty sure this is =
the wrong syntax?<br></div><div>&nbsp; }</div><div><br></div><div>&nbsp;=
 public function getId(): T;<br></div><div>&nbsp; public function setId(=
T $id): void;<br></div><div>}<br></div><div><br></div><div>class StringI=
d implements Id&lt;string&gt; { /* ... */ }<br></div><div>class IntId im=
plements Id&lt;int&gt; { /* ... */ }</div><div><br></div><div>For codeba=
ses (like the one I work with every day) identifiers may be a string or =
int and right now, that interface can't exist.</div><div><br></div><bloc=
kquote type=3D"cite" id=3D"qt" style=3D""><p><span style=3D"text-wrap:wr=
ap;">But sure, generic interfaces and monomorphized generic traits are p=
erfectly implementable today. In fact, I'd definitely suggest we'd start=
 out by implementing these, orthogonally from actual class generics.</sp=
an><br></p><p><span style=3D"text-wrap:wrap;"></span><br></p><p><span st=
yle=3D"text-wrap:wrap;">Bob</span><br></p><p><span style=3D"text-wrap:wr=
ap;"></span><br></p></blockquote><div><br></div><div id=3D"sig121229152"=
>=E2=80=94 Rob<br></div></body></html>
--690eb8d82314400b8e278950a1440d7c--