[EventSubscriber] Infer subscribed events from listener parameters

[derrabus]

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	N/A
License	MIT
Doc PR	N/A

Since event names are FQCN now, I though maybe we could reduce the verbosity of event subscribers a bit by omitting the keys in the array returned by getSubscribedEvents(). This PR allows to rewrite this subscriber …

final class MySubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents()
    {
        return [RequestEvent::class => 'onRequest'];
    }

    public function onRequest(RequestEvent $event): void
    {
    }
}

… like this …

final class MySubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents()
    {
        return ['onRequest'];
    }

    public function onRequest(RequestEvent $event): void
    {
    }
}

Drawbacks:

• The referenced method has to be defined on the subscriber. When using the event name as a key, the subscriber could handle the event within the magic __call() method.
• This approach does not work on parameter-less listener methods for obvious reasons.
• Reflection usage comes with a small performance penalty. When using the dispatcher standalone, the addSubscriber() call will be slightly slower on a subscriber without event names as keys. When using DI, only the container compilation will be slightly slower.

[nicolas-grekas]

Are the drawbacks worth the explicitness downgrade?

[derrabus]

I'd say yes. I like the reduced redundancy. The type-hint on the method parameter is explicit enough if event name === FQCN. Regarding the drawbacks, if I look at the event subscribers in my current applications:

• I never use __call() to handle an event.
• The method usually has a properly type-hinted parameter or no parameter at all.
• I don't care much if container compilation takes a few µs more as long as the runtime performance is not impacted.

Also, I wouldn't deprecate or change the current layout of the array. You can even mix both styles. So, if you have a parameter-less listener method, you can still fall back to providing the event name as key.

[nicolas-grekas]

this should be in the pass, i.e. compile-time only

[nicolas-grekas]

Hum, but this would mean getSubscribedEvents wouldn't by that decoupled anymore as the pass would be a requirement to allow bypassing the event name.
And on the other side, I don't like having the reflection-related logic in the main object.
I think I'm 👎 on this idea sorry.

[derrabus]

this should be in the pass, i.e. compile-time only

The logic is executed on compile-time only – in the full-stack framework scenario. If I moved the reflection logic into the pass, this feature would become a DI-only feature as it would not work anymore when using the dispatcher standalone.

[nicolas-grekas]

Yes, exactly what I meant also.
We just closed #30760 to save the code from doing more Reflection, even at compile time.
It would be consistent to close this one also, sorry again.

[derrabus]

All right.