[RFC] An unobtrusive EventDispatcher (not before 3.0) #7792
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Apr 22, 2013
|
Closing this PR as this is not something I want to discuss at this point. see #7627 for more details. |
|
@fabpot Would you consider it if it only passed the additional |
|
Ping @perprogramming |
|
+1! It is really a disadvantage of Symfony\Component\EventDispatcher that event objects have to extend a base class. It forces a bad coupling on client code.. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea of this PR is to separate the how of Event propagation from the what of Events.
Currently (2.x), client code has to inherit from
Eventto carry information about event propagation along. This is factored out into a separate class,EventPropagation.The benefit for client code is that POPOs (anything) can be used as the Event and that these objects need not be aware of event dispatching at all. The object passed along is not modified during propagation, at least not by the Event Dispatcher system.
The new
EventPropagationclass is passed as the second argument to listeners. Besides stopping propagation, it allows to obtain both theEventDispatcherinitially used to send off the Event (f. e. to trigger another one on the same channel) as well as the dispatcher a listener was registered with (in case a listener is multiply-subscribed and the dispatcher matters).This is a spin-off from #7627 and we cannot get it before 3.0 due to API changes. Anyway, I'd like to start a discussion with it :-).