8000 [EventDispatcher] Declare return type of `getSubscribedEvents()` by Warxcell · Pull Request #41995 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[EventDispatcher] Declare return type of getSubscribedEvents() #41995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 14, 2021

Conversation

Warxcell
Copy link
Contributor
@Warxcell Warxcell commented Jul 5, 2021

Fixes

Method getSubscribedEvents() return type has no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iterable-type

Q A
Branch? 4.4
Bug fix? kinda
New feature? no
Deprecations? no
Tickets Fix
License MIT
Doc PR

Fixes 

Method getSubscribedEvents() return type has no value type specified in iterable type array.  
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iterable-type
@carsonbot carsonbot added this to the 4.4 milestone Jul 5, 2021
@Warxcell Warxcell changed the title Declare returned type. [EventDispatcher] Declare returned type. Jul 5, 2021
@carsonbot carsonbot changed the title [EventDispatcher] Declare returned type. Declare returned type. Jul 5, 2021
@derrabus derrabus changed the title Declare returned type. [EventDispatcher] Declare return type of getSubscribedEvents() Jul 5, 2021
@@ -43,7 +43,7 @@ interface EventSubscriberInterface
* The code must not depend on runtime state as it will only be called at compile time.
* All logic depending on runtime state must be put into the individual methods handling the events.
*
* @return array The event names to listen to
* @return array<string, mixed> The event names to listen to
Copy link
Contributor
@sstok sstok Jul 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use something more explicit than mixed? Personally I try to use union's as much as possible.
Like array<string, string|array{0: string}|array{0: string, 1: int}|array<int, array{0: string}|array{0: string, 1: int}>>

And yes it's a bit verbose 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's actually not the right signature. the right one is this:

array<string, string|array{0: string, 1?: int}|list<array{0: string, 1?: int}>>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, you edited in the meantime. Your new proposal is too verbose due to not using the optional key for the priority

Copy link
Member

Choose a reason for hiding this comment

8000 The reason will be displayed to describe this comment to others. Learn more.

This notation is not understood by all tools yet. I think the current type is precise enough.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL the list pseudo-type 😄 and optional keys.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://psalm.dev/r/0e971e1c02 but for some reason it doesn't like it :D

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't use @template for this (as that's a generic and implies the return type), you need to define a custom type instead but Pslam doesn't support this it seems.

I only use PHPStan atm because Psalm doesn't support PHP 8 yet 😞

@derrabus
Copy link
Member

Thank you @Warxcell.

@derrabus derrabus merged commit 9327031 into symfony:4.4 Jul 14, 2021
@derrabus
Copy link
Member

FYI @nicolas-grekas: This change seems to confuse our patch-types script: https://github.com/symfony/symfony/runs/3068884172#step:7:17

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0