Skip to content

[Messenger] internal cleanups #28908

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 21, 2018
Merged

Conversation

nicolas-grekas
Copy link
Member

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

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 -

From the updated changelog:

  • MessengerDataCollector::getMessages() returns an iterable, not just an array anymore
  • AbstractHandlerLocator is now internal
  • HandlerLocatorInterface::resolve() has been replaced by getHandler(Envelope $envelope)
  • SenderLocatorInterface::getSenderForMessage() has been replaced by getSender(Envelope $envelope)
  • SenderInterface::send() returns void
  • some internal simplifications

@nicolas-grekas nicolas-grekas force-pushed the messenger-cleanup branch 2 times, most recently from b9ca4e7 to 0dac059 Compare October 17, 2018 15:59
*/
abstract class AbstractHandlerLocator implements HandlerLocatorInterface
{
public function resolve($message): callable
public function getHandler(Envelope $envelope, bool $allowNoHandler = false): ?callable
Copy link
Member Author

Choose a reason for hiding this comment

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

$allowNoHandler is not used for now, but I'd like we add it right now in the interface and replace AllowNoHandlerMiddleware later on (using exceptions as a signaling mean is making the "no-handler" path slow for no real reasons.)

Copy link
Contributor

Choose a reason for hiding this comment

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

It's internal, so you can add it later, as part of another PR please 😉

Copy link
Member Author

Choose a reason for hiding this comment

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

(agreed, removed)

Copy link
Contributor

@sroze sroze left a comment

Choose a reason for hiding this comment

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

Can you remove your allowNoHandler please?


if ($sender) {
$sender->send($envelope);

if (!$this->mustSendAndHandle($envelope->getMessage())) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Keeping the private function increases the readability, I'd keep it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Honeslty, I've had a hard time understanding what this was about. The private method didn't help me. I think the comment would make a better job. I'd keep the change :)

*/
abstract class AbstractHandlerLocator implements HandlerLocatorInterface
{
public function resolve($message): callable
public function getHandler(Envelope $envelope, bool $allowNoHandler = false): ?callable
Copy link
Contributor

Choose a reason for hiding this comment

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

It's internal, so you can add it later, as part of another PR please 😉

*/
public function send(Envelope $envelope);
Copy link
Contributor

Choose a reason for hiding this comment

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

Sneaky. Surely sender will want to return things. It very similar to the : void on the MessageBusInterface. Sounds reasonable if we provide a clear path for the use-cases returning something.

Copy link
Member Author

@nicolas-grekas nicolas-grekas Oct 21, 2018

Choose a reason for hiding this comment

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

We don't have any use case in core for this, and the code is extensible enough so that people can write their own way of getter something back (ie a middleware + an extended SendInterface of their own, that's nothing standard/core anyway).
Better close the interface to ease maintainance from core team's pov.

@nicolas-grekas nicolas-grekas force-pushed the messenger-cleanup branch 2 times, most recently from 0b3dc43 to b45836e Compare October 21, 2018 14:30
@nicolas-grekas
Copy link
Member Author

PR rebased and comments addressed, ready.

}

/**
* {@inheritdoc}
Copy link
Contributor

Choose a reason for hiding this comment

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

This should have stayed as before

usort($messages, function (array $a, array $b): int {
return $a[1] > $b[1] ? 1 : -1;
});
usort($messages, function ($a, $b) { return $a[1] <=> $b[1]; });
Copy link
Contributor

Choose a reason for hiding this comment

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

👌

@sroze
Copy link
Contributor

sroze commented Oct 21, 2018

Thank you @nicolas-grekas.

@sroze sroze merged commit 4a3edd0 into symfony:master Oct 21, 2018
sroze added a commit that referenced this pull request Oct 21, 2018
This PR was merged into the 4.2-dev branch.

Discussion
----------

[Messenger] internal cleanups

| 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        | -

From the updated changelog:
 * `MessengerDataCollector::getMessages()` returns an iterable, not just an array anymore
 * `AbstractHandlerLocator` is now internal
 * `HandlerLocatorInterface::resolve()` has been replaced by `getHandler(Envelope $envelope)`
 * `SenderLocatorInterface::getSenderForMessage()` has been replaced by `getSender(Envelope $envelope)`
 * `SenderInterface::send()` returns `void`

+ some internal simplifications

Commits
-------

4a3edd0 [Messenger] internal cleanups
@nicolas-grekas nicolas-grekas deleted the messenger-cleanup branch October 23, 2018 12:56
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.

4 participants