Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125071
Precedence: bulk
MIME-Version: 1.0
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net> <AM8P250MB01706B1541E1283F4065B94AE28C2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <d5fa624c-0c0f-4fed-adea-4f7e0e3a6728@app.fastmail.com>
In-Reply-To: <d5fa624c-0c0f-4fed-adea-4f7e0e3a6728@app.fastmail.com>
Date: Tue, 20 Aug 2024 16:03:36 +0200
Message-ID: <CAP1Jc10JtHed0ubtOHvaHFigxMBwhR1mZi4ye8Qa+DT2doD0Pg@mail.gmail.com>
Subject: Re: [PHP-DEV] State of Generics and Collections
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Larry,

On Tue, Aug 20, 2024 at 3:32=E2=80=AFAM Larry Garfield <larry@garfieldtech.=
com> wrote:
> > In fact, generic traits (essentially statically replacing the generic
> > arguments at link-time) would be an useful feature which would remain
> > useful even if we had fully reified generics.
> > I recognize that some functionality will need support of internal
> > zend_object_handlers. But that's not a blocker, we might provide some
> > default internal traits with PHP, enabling the internal class handlers.
> > So to summarize, I would not continue on that path, but really invest
> > into monomorphizable generic traits instead.
>
> Interesting.  I have no idea why Arnaud has mainly been investigating rei=
fied generics rather than monomorphized, but a monomorphized trait has pote=
ntial, I suppose.  That naturally leads to the question of whether monomorp=
hized interfaces would be possible, and I have no idea there.  (I still hol=
d out hope that Levi will take another swing at interface-default-methods.)
>
> Though this still wouldn't be a path to full generics, as you couldn't de=
clare the inner type of an object at creation time, only code time.  Still,=
 it sounds like an area worth considering.

Monomorphization as a solution to generic classes has a memory usage
issue (it requires duplicating the class entry, methods, props, and
also opcodes if method bodies can reference type parameters), and does
not solve all the complexity:
https://github.com/PHPGenerics/php-generics-rfc/issues/44.

This would be less a problem for traits, as there is already some
amount of duplication.

Best Regards,
Arnaud