-
-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[Messenger] remove classifying sub-namespaces in favor of semantic ones #28947
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
8accff4 to
34a8c2d
Compare
d024de9 to
1a3c57e
Compare
1a3c57e to
640cced
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completely makes sense to me.
How do you feel with the AmqpExt in the Messenger/Transport ns? Where would live the Memory/KernelTerminateTransport and upcoming transport bridges/implems if any?
| use Symfony\Component\Messenger\Transport\Enhancers\StopWhenMemoryUsageIsExceededReceiver; | ||
| use Symfony\Component\Messenger\Transport\Enhancers\StopWhenMessageCountIsExceededReceiver; | ||
| use Symfony\Component\Messenger\Transport\Enhancers\StopWhenTimeLimitIsReachedReceiver; | ||
| use Symfony\Component\Messenger\Transport\StopWhenMemoryUsageIsExceededReceiver; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Symfony\Component\Messenger\Transport\StopWhenMemoryUsageIsExceededReceiver
+ Symfony\Component\Messenger\Transport\Receiver\StopWhenMemoryUsageIsExceededReceiver(same for the two ones below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed thanks
I think they're OK in their own sub-namespace - same for other future transports - unless they need just one class I suppose. |
640cced to
350a20c
Compare
|
The suffix Decorator on |
350a20c to
9d8a666
Compare
makes sense, removed. |
9d8a666 to
16afb5e
Compare
|
Thank you @nicolas-grekas. |
… of semantic ones (nicolas-grekas) This PR was merged into the 4.2-dev branch. Discussion ---------- [Messenger] remove classifying sub-namespaces in favor of semantic ones | Q | A | ------------- | --- | Branch? | 4.2 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - While working on the component, I found it hard to discover the meaning of the `Asynchronous` and `Enhancers` sub-namespaces. Now that I know the component better, I understand they're only classifying namespaces with no specific technical semantics. I'd like to remove them to make the component easier to discover. This PR introduces a few new semantic sub-namespaces instead. From the changelog: * Classes in the `Middleware\Enhancers` sub-namespace have been moved to the `Middleware` one * Classes in the `Asynchronous\Routing` sub-namespace have been moved to the `Transport\Sender\Locator` sub-namespace * The `Asynchronous/Middleware/SendMessageMiddleware` class has been moved to the `Middleware` namespace * `SenderInterface` and `ChainSender` classes have been moved to the `Transport\Sender` sub-namespace * `ReceiverInterface` and its implementations have been moved to the `Transport\Receiver` sub-namespace Commits ------- 16afb5e [Messenger] remove classifying sub-namespaces in favor of semantic ones
While working on the component, I found it hard to discover the meaning of the
AsynchronousandEnhancerssub-namespaces. Now that I know the component better, I understand they're only classifying namespaces with no specific technical semantics.I'd like to remove them to make the component easier to discover.
This PR introduces a few new semantic sub-namespaces instead.
From the changelog:
Middleware\Enhancerssub-namespace have been moved to theMiddlewareoneAsynchronous\Routingsub-namespace have been moved to theTransport\Sender\Locatorsub-namespaceAsynchronous/Middleware/SendMessageMiddlewareclass has been moved to theMiddlewarenamespaceSenderInterfaceandChainSenderclasses have been moved to theTransport\Sendersub-namespaceReceiverInterfaceand its implementations have been moved to theTransport\Receiversub-namespace