d901c6d846
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] made dispatch() and handle() return void
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Middlewares and dispatchers should not return any value. Forwarding back the results from handlers breaks the scope of the component. The canonical example of some bad design this can lead to is `ChainHandler`: how can the caller know that there is one in the chain and that it should expect an array as a return value? More generally, how can a caller know what to expect back from a call to dispatch()? I think we should not allow such broken designs.
Instead, we should favor east-oriented design: if one needs a command bus, one would have to dispatch a proper command object - and if a result is expected back, it should be done via a setter on the dispatched command - or better, a callback set on the command object. This way we play *by the rules* of the type-system, not against.
Commits
-------
|
||
---|---|---|
.. | ||
Asset | ||
BrowserKit | ||
Cache | ||
Config | ||
Console | ||
CssSelector | ||
Debug | ||
DependencyInjection | ||
DomCrawler | ||
Dotenv | ||
EventDispatcher | ||
ExpressionLanguage | ||
Filesystem | ||
Finder | ||
Form | ||
HttpFoundation | ||
HttpKernel | ||
Inflector | ||
Intl | ||
Ldap | ||
Lock | ||
Messenger | ||
OptionsResolver | ||
Process | ||
PropertyAccess | ||
PropertyInfo | ||
Routing | ||
Security | ||
Serializer | ||
Stopwatch | ||
Templating | ||
Translation | ||
Validator | ||
VarDumper | ||
VarExporter | ||
WebLink | ||
Workflow | ||
Yaml |