On Fri, Aug 23, 2024, at 6:48 AM, Roman Pronskiy wrote:
> On Mon, Aug 19, 2024 at 7:11 PM Derick Rethans <der...@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-collections/
>
> 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 –
> https://github.com/php-static-analysis/attributes – it could
> potentially be a better alternative of recognising “official” 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 that
today, *we already have erased generics*, via PHPStan/Psalm. That's one reason
I am, personally, against erased generics in the language proper. They don't
really offer anything we don't have already.
Moving those definitions to attributes is certainly possible, though AFAIK 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 classes. 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 would 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 favor going
all the way to the latter (no-string-parsing attributes), and revising the
syntax along the way. (The current syntax used by SA tools is 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 equally 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 once 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 current
syntax. :-) Two, that seems unwise as long as PHP still has an option to
remove comments/docblocks at compile time. Even if it's not used 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 "endorsing" anything.
(With the inexplicable exception of Docuwiki.)
--Larry Garfield
