Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Merged
merged 1 commit into from
Oct 25, 2018

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Oct 22, 2018

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

@nicolas-grekas nicolas-grekas added this to the 4.2 milestone Oct 22, 2018
@nicolas-grekas nicolas-grekas requested a review from sroze as a code owner October 22, 2018 13:12
@nicolas-grekas nicolas-grekas force-pushed the messenger-no-subns branch 2 times, most recently from d024de9 to 1a3c57e Compare October 22, 2018 17:26
Copy link
Contributor

@ogizanagi ogizanagi left a 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;
Copy link
Contributor

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed thanks

@nicolas-grekas
Copy link
Member Author

How do you feel with the AmqpExt

I think they're OK in their own sub-namespace - same for other future transports - unless they need just one class I suppose.

@Tobion
Copy link
Contributor

Tobion commented Oct 25, 2018

The suffix Decorator on ActivationMiddlewareDecorator is not consistent with the rest. All other decorators don't have this suffix like TraceableMiddleware

@nicolas-grekas
Copy link
Member Author

The suffix Decorator on ActivationMiddlewareDecorator is not consistent with the rest

makes sense, removed.

@sroze
Copy link
Contributor

sroze commented Oct 25, 2018

Thank you @nicolas-grekas.

@sroze sroze merged commit 16afb5e into symfony:master Oct 25, 2018
sroze added a commit that referenced this pull request Oct 25, 2018
… 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
@nicolas-grekas nicolas-grekas deleted the messenger-no-subns branch October 25, 2018 09:41
This was referenced Nov 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants