Repository navigation
support for class-string-map<T of Foo> #281
Description
Activity
Hi, I don't want parser changes that would allow invalid syntax on other types. We want to support
class-string-map<T of Foo>but at the same time I still wantarray<T of Foo>to be a parse error because it does not make sense.So I guess there needs to be a one-off condition for the
class-string-maptype here in the parser.Or we can invent a new syntax like we have for generic callables and Closures #232.
That doesn't sound like a "definitely not" to me. I can check the impact of an implementation that covers your requirements to prevent invalid type definitions. And see what the best approach is.
I think we should not introduce something new as psalm is already supporting this, so it would be harder to be compatible with both tools. Unless there are very good reasons to do a different syntax.
I'm not fully aware of the use case phpstan should cover when we allow this syntax. I made the assumption that it would narrow down the possible types of
Twhen defining a generic? It might sound strange that I do this request without deep knowledge of the type definition. But I'm mostly finding a way to be consistent across the php tooling without too much impact.
I was investigating the option to add support for
class-string-map<T of Foo>and found #246, and also phpstan/phpstan#9521. According to @ondrejmirtes in #246 this syntax should already be supported by this library. But is it not.I'm wondering if we should introduce the syntax, and how this would look like. I can help with the implementation in the parser. But not without an agreement on how this would work on the
GenericType.I would suggest to add a
$boundtype on theGenericTypewhich is equal to the behavior on@templateThis is needed to the mentioned change in phpstan and phpDocumentor/TypeResolver#266. Support in the parser would at least prevent a crash in the parser.
Thanks for this library! 🎉