Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125060
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 19 Aug 2024 20:31:05 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <d5fa624c-0c0f-4fed-adea-4f7e0e3a6728@app.fastmail.com>
In-Reply-To: 
 <AM8P250MB01706B1541E1283F4065B94AE28C2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <AM8P250MB01706B1541E1283F4065B94AE28C2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Subject: Re: [PHP-DEV] State of Generics and Collections
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Aug 19, 2024, at 5:16 PM, Bob Weinand wrote:

> Regarding the Collections PR, I personally really don't like it:
>
>  =E2=80=A2 It implements something which would be trivial if we had re=
ified=20
> generics. If this ever gets merged, and generics happen later, it woul=
d=20
> be probably outdated and quirkiness the language has to carry around.
>  =E2=80=A2 It's not powerful. But rather a quite limited implementatio=
n. 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 unique=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.

I think we weren't that clear on that section, then.  The intent is that=
 dedicated collection classes are, well, classes.  They can contain addi=
tional methods, and probably can override the parent methods; though the=
 latter may have some trickiness if trying to access the internal data s=
tructure, 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 fu=
rther.)

>  =E2=80=A2 It's a very specialized structure/syntax, not extensible fo=
r=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 be=20
> doable, regardless of the rest of the generics investigation.
> In fact, generic traits (essentially statically replacing the generic=20
> arguments at link-time) would be an useful feature which would remain=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 some=20
> default internal traits with PHP, enabling the internal class handlers.
> So to summarize, I would not continue on that path, but really invest=20
> into monomorphizable generic traits instead.

Interesting.  I have no idea why Arnaud has mainly been investigating re=
ified generics rather than monomorphized, but a monomorphized trait has =
potential, I suppose.  That naturally leads to the question of whether m=
onomorphized interfaces would be possible, and I have no idea there.  (I=
 still hold out hope that Levi will take another swing at interface-defa=
ult-methods.)

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.

--Larry Garfield