[Contracts][EventDispatcher] add EventDispatcherInterface to symfony/contracts and use it where possible #30691
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
nicolas-grekas
commented
Mar 25, 2019
| xdebug_enable(); | ||
| } | ||
| } | ||
| throw new AutowiringFailedException($this->currentId, $failureMessage); |
There was a problem hiding this comment.
not directly related but was still needed to make tests pass locally
f7ad7c0 to
a83fde3
Compare
|
Green! (failure unrelated) |
…contracts and use it where possible
a83fde3 to
3c3db2f
Compare
fabpot
reviewed
Mar 25, 2019
fabpot
approved these changes
Mar 25, 2019
xabbuh
requested changes
Mar 26, 2019
| @@ -29,6 +29,10 @@ | |||
| "conflict": { | |||
| "symfony/dependency-injection": "<3.4" | |||
| }, | |||
| "provide": { | |||
| "psr/event-dispatcher-implementation": "1.0", | |||
There was a problem hiding this comment.
Can we do that (because this is only true when the psr/event-dispatcher package is present)?
There was a problem hiding this comment.
It still does provide the implementation - when the package is present of course. When it isn't, nothing can provide it by definition. So yes we can.
xabbuh
approved these changes
Mar 26, 2019
|
Thank you @nicolas-grekas. |
fabpot
added a commit
that referenced
this pull request
Mar 27, 2019
…ace to symfony/contracts and use it where possible (nicolas-grekas) This PR was merged into the 4.3-dev branch. Discussion ---------- [Contracts][EventDispatcher] add EventDispatcherInterface to symfony/contracts and use it where possible | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - This PR adds a new `EventDispatcherInterface` in `Contracts`. This interface contains only one method: `dispatch($event, $eventName)`. That covers almost all use cases of the event dispatcher in components (some use add/removeListeners/Subscribers but they are a minority.) While doing so, it allows dispatching any objects as events - not only instances of `Event`. This allows decoupling e.g. `Messenger` from the `EventDispatcher` component. Next steps could be about planning to remove the base `Event` class from some concrete event classes and/or moving `EventSubscriberInterface` to `symfony/contracts`. It would allow decoupling e.g. `Workflow` from the component - but that's too far away for now, let's think about it in 5.1. Commits ------- 3c3db2f [Contracts][EventDispatcher] add EventDispatcherInterface to symfony/contracts and use it where possible
Merged
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.
This PR adds a new
EventDispatcherInterfaceinContracts. This interface contains only one method:dispatch($event, $eventName). That covers almost all use cases of the event dispatcher in components (some use add/removeListeners/Subscribers but they are a minority.)While doing so, it allows dispatching any objects as events - not only instances of
Event.This allows decoupling e.g.
Messengerfrom theEventDispatchercomponent.Next steps could be about planning to remove the base
Eventclass from some concrete event classes and/or movingEventSubscriberInterfacetosymfony/contracts. It would allow decoupling e.g.Workflowfrom the component - but that's too far away for now, let's think about it in 5.1.