Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[EventDispatcher] swap arguments of dispatch() to allow registering events by FQCN #28920
PR green and ready.
From UPGRADE files:
Thanks for the early reviews. I still have a few edges to fix (as spotted by the CI).
two sides: allowing one to subscribe to events using FQCN:
that's what happens now :)
at least for BC, to map
The aliases being compile-time only mean that any code meant to work with components only and not FrameworkBundle cannot use them, and that Form aliases are useless (as these are not dispatched on the dispatcher configured by FrameworkBundle as each Form instance has its own EventDispatcher)
I like this step a lot. This was one of my "favorite" drawback of the
I can share some thoughts/ideas of my event handling experience, probably it may help to improve the component. I tried to not discuss it here because you are locked with BC policies. But if you want to change something...
I think you are aware of debates regarding using term "event" for this kind of service. In my opinion, Symfony provides hook dispatcher/manager, not event one. You can say that it's just matter of taste, but it has architecture impacts. You lose ability to make async event handlers without evidence that abstraction is very leaky. It was discussed here, for example: #23441. And regarding naming here, for instance: https://twitter.com/mathiasverraes/status/1013654989682741248. Probably, you will never change it, but it's very noticeable thing that comes in mind when we talk about this component.
This little "terminology disagreement" leads to 2 completely different concepts of EventDispatcher/Bus. "That" event bus:
I prefer the following logic:
P.S. Avoiding string identifiers for events gives another advantage: developers start to be more reasonable regarding event classes and make them more "fine-grained": not
@unkind I think you confuse two concepts here, the Symfony Event Dispatcher is based on the https://en.wikipedia.org/wiki/Mediator_pattern which allows "events" to be mutable, it's naming is definitely off :) changing this fundamental logic is a major BC break, instead Symfony would have to introduce another component or class that truly implements immutable events.
Async handling requires more work as you need to handle serialization and transportation which the Messenger component already solves nicely. Yes, you don't have priorities, but this feature could be added.
I'm not sure about this, I explicitly stated that
It was just a little rant about naming in the first place. Naming disregard is a problem.