Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125146
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 09:26:57 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e69928c7-a471-4e00-878e-8bbda4d49c4f@app.fastmail.com>
In-Reply-To: 
 <CADZ9LSXN-_oSUumwXmka7xgEy9PsEjUn+O4YGPP-2QPwyaB5_g@mail.gmail.com>
References: <1b59392a-68cb-36eb-0fef-977ac7113520@php.net>
 <CADZ9LSXN-_oSUumwXmka7xgEy9PsEjUn+O4YGPP-2QPwyaB5_g@mail.gmail.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 Fri, Aug 23, 2024, at 6:48 AM, Roman Pronskiy wrote:
> On Mon, Aug 19, 2024 at 7:11=E2=80=AFPM Derick Rethans <derick@php.net=
> wrote:
>>
>> Arnaud, Larry, and I have been working on an article describing the
>> state of generics and collections, and related "experiments".
>>
>> You can find this article on the PHP Foundation's Blog:
>> https://thephp.foundation/blog/2024/08/19/state-of-generics-and-colle=
ctions/
>
> Thank you Arnaud, Derick, Larry for the article.
>
> Do you consider the path of not adding generics to the core at all? In
> fact, this path is implicitly taken during the last years. So maybe it
> makes sense to enforce that status quo?
>
> Potential steps:
> - Make the current status quo official by recognizing generics PHPDoc
> syntax as The Generics for PHP. Just adding a php.net manual page will
> do.
> - Recognize Composer as the official PHP tool. It's currently not
> mentioned on php.net at all.
> - Suggest using PHPStan or Psalm for generics and type checks.
> - Add an official specification for generics in the PHP manual to
> eliminate semantic variances between tools.
>
> This will keep the core simple and reduce the maintenance burden, not
> increase it.
>
> Moreover, it does not contradict with any other implementation
> mentioned in the article, should they happen. In fact, it could be a
> first baby-step for any of them.
>
> There is also an attempt to do generics via attributes =E2=80=93
> https://github.com/php-static-analysis/attributes =E2=80=93 it could
> potentially be a better alternative of recognising =E2=80=9Cofficial=E2=
=80=9D syntax,
> because unlike PHPDocs, attributes can be available in core and the
> syntax is checked.
>
> What do you folks think?
>
> -Roman

The null option is always an option, yes.  The thing to understand is th=
at today, *we already have erased generics*, via PHPStan/Psalm.  That's =
one reason I am, personally, against erased generics in the language pro=
per.  They don't really offer anything we don't have already.

Moving those definitions to attributes is certainly possible, though AFA=
IK both the PHPStan and Psalm devs have expressed zero interest in it.  =
Part of the challenge is that such an approach will either still involve=
 string parsing, or will involve a lot of deeply nested attribute classe=
s.  For instance, if today you'd write:

/**
 * @var array<string, Dict<string, Foo>>
 */
protected array $foos;

(An entirely reasonable lookup table for some circumstances).  What woul=
d that be in attributes?

This would still need string parsing:

#[GenericType('string', 'Dict<string, Foo>>')]

And a form that doesn't need string parsing:

#[DictType('string', new Dict('string', Foo::class))]

Which is getting kinda ugly fast.

All else equal, if we have to keep generics to implicit/erased, I'd favo=
r going all the way to the latter (no-string-parsing attributes), and re=
vising the syntax along the way.  (The current syntax used by SA tools i=
s decidedly weird compared to most generic languages, making it hard to =
follow.)

If instead we used attributes for reified generics, then we have all the=
 same challenges that make reified generics hard, just with a different =
syntax.  As I understand it (again, Arnaud is free to correct me), these=
 two syntaxes would be equally straightforward to parse, but also equall=
y complex to implement the runtime logic for:

#[DictType('string', new Dict('string', Foo::class))]
protected array $foo;

protected Dict<string, Dict<'string', Foo>> $foo;

The latter is more compact and typical of our sibling languages, but onc=
e the parser is done, all of the other challenges are the same.

As for making docblock generics "official", one, as I noted I hate the c=
urrent syntax. :-)  Two, that seems unwise as long as PHP still has an o=
ption to remove comments/docblocks at compile time.  Even if it's not us=
ed much anymore, the option is still there, AFAIK.

And that's before we even run into the long-standing Internals aversion =
to even recognizing the existence of 3rd party tools for fear of "endors=
ing" anything.  (With the inexplicable exception of Docuwiki.)

--Larry Garfield