Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Messenger] Add TransportInterface as first class citizen sender+receiver#27164

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
sroze merged 1 commit intosymfony:4.1fromnicolas-grekas:messenger-transport
May 8, 2018

Conversation

@nicolas-grekas
Copy link
Member

@nicolas-grekasnicolas-grekas commentedMay 5, 2018
edited
Loading

QA
Branch?master
Bug fix?no
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets-
LicenseMIT
Doc PR-

The current design misses an opportunity to reuse the same connection for the sender and the receiver parts of a transport. By makingTransportInterface a first class citizen, we simplify the wiring logic, we allow sharing the same connection for both the sender and the receiver, and we provide a natural point to lazily create the connection.

Live from Las Vegas :)

image

ro0NL and yceruto reacted with thumbs up emojiyceruto reacted with hooray emoji
Copy link
Contributor

@srozesroze left a comment

Choose a reason for hiding this comment

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

I like the idea.

Interestingly, that was in the original proposal but@lyrixx had a strong 👎 for it being a unnecessary abstraction layer.

* {@inheritdoc}
*/
publicfunctionsend($message)
publicfunctionsend($message):void
Copy link
Contributor

Choose a reason for hiding this comment

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

I’m not fond of the idea of enforcingvoid as a result. Senders might return something later on, we shouldn’t close that door IMHO.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Removing void should be ok for the bc policy. Seesymfony/symfony-docs#9717

Copy link
Contributor

Choose a reason for hiding this comment

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

Fair enough.

*/
publicfunctionreceive(callable$handler):void
{
($this->receiver ??$this->getReceiver())->receive($hander);
Copy link
Member

Choose a reason for hiding this comment

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

It seems ternary operator fits better here (same below) ?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Not sure what you mean, doesn't feel like to me :)

Copy link
Contributor

Choose a reason for hiding this comment

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

I think@yceruto mean next variant:

$this->receiver ?$this->receiver->receive($hander) ?$this->getReceiver()->receive($hander)

Copy link
Member

@ycerutoycerutoMay 6, 2018
edited
Loading

Choose a reason for hiding this comment

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

I meant($this->receiver ?: $this->getReceiver())-> instead, as$this->receiver is always defined I don't see the need for??, but probably I'm missing something here :)

Copy link
Contributor

@ogizanagiogizanagiMay 6, 2018
edited
Loading

Choose a reason for hiding this comment

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

$this->receiver isnull until$this->getReceiver() is called a first time. So makes sense to use thenull-coalescing operator rather than ternary for this :)

Copy link
Member

@ycerutoycerutoMay 6, 2018
edited
Loading

Choose a reason for hiding this comment

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

According tothe manual:

The null coalescing operator (??) has been added as syntactic sugar for the common case of needing to use a ternary in conjunction with isset(). It returns its first operand ifIT EXISTS and is not NULL; otherwise it returns its second operand.

So ternary operator fits better in this case as$this->receiver always exists (i.e. this var is defined always), but NVM it's just a detail,?? works fine too.

@fabpot
Copy link
Member

This one should be rebased

@nicolas-grekas
Copy link
MemberAuthor

PR rebased

@nicolas-grekasnicolas-grekas changed the base branch frommaster to4.1May 7, 2018 15:04
@sroze
Copy link
Contributor

Thank you@nicolas-grekas.

@srozesroze merged commit379b8eb intosymfony:4.1May 8, 2018
sroze added a commit that referenced this pull requestMay 8, 2018
…n sender+receiver (nicolas-grekas)This PR was merged into the 4.1 branch.Discussion----------[Messenger] Add TransportInterface as first class citizen sender+receiver| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -The current design misses an opportunity to reuse the same connection for the sender and the receiver parts of a transport. By making `TransportInterface` a first class citizen, we simplify the wiring logic, we allow sharing the same connection for both the sender and the receiver, and we provide a natural point to lazily create the connection.Live from Las Vegas :)![image](https://user-images.githubusercontent.com/243674/39658543-93c7120c-4fca-11e8-9f11-797953b3ee98.png)Commits-------379b8eb [Messenger] Add TransportInterface as first class citizen sender+receiver
@ycerutoyceruto mentioned this pull requestMay 8, 2018
2 tasks
sroze added a commit that referenced this pull requestMay 8, 2018
This PR was merged into the 4.1 branch.Discussion----------[Messenger] Fix AMQP Transport| Q             | A| ------------- | ---| Branch?       | 4.1| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#27164| License       | MIT| Doc PR        | -- [x] Fix typo- [x] Fix create `Connection` instance- [ ] Add testCommits-------b8a4d5a Fix AmqpTransport
sroze added a commit that referenced this pull requestMay 8, 2018
…nterface (ogizanagi)This PR was merged into the 4.1 branch.Discussion----------[Messenger] Fix AMQP Transport factory & TransportFactoryInterface| Q             | A| ------------- | ---| Branch?       | 4.1 <!-- see below -->| Bug fix?      | yes| New feature?  | no <!-- don't forget to update src/**/CHANGELOG.md files -->| BC breaks?    | no     <!-- seehttps://symfony.com/bc -->| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->| Fixed tickets |#27164  <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | N/ASeems like we did review a bit fast here 😅Commits-------98967cd [Messenger] Fix AMQP Transport factory & TransportFactoryInterface
sroze added a commit that referenced this pull requestMay 8, 2018
This PR was merged into the 4.1 branch.Discussion----------[Messenger] Fix the transport factory after moving it| Q             | A| ------------- | ---| Branch?       | 4.1| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#27164| License       | MIT| Doc PR        | ø`ChainTransportFactory` was renamed but the `messenger.xml` wasn't changed.Commits-------7a091d9 Fix the transport factory after moving it
weaverryan added a commit to symfony/symfony-docs that referenced this pull requestMay 9, 2018
This PR was submitted for the master branch but it was squashed and merged into the 4.1 branch instead (closes#9727).Discussion----------[Messenger] Update the messenger documentation- [x]Fixes#9641 with the middleware configuration.- [x]Fixes#9617 with the multiple bus configuration.- [x] Change adapters to transports (waiting merge:symfony/symfony#27129)- [x] middlewares config entry is renamed middleware (symfony/symfony#27177)- [x] in the config, message buses names are the full service id you'll use (symfony/symfony#27162)- [x] Add TransportInterface as first class citizen sender+receiver (symfony/symfony#27164)Commits-------c3c3528 Few updates following review64bfd75 Change wording and don't use `.`-based services so it's just clearere1f3b5a Fix the formating of the method name9b7b85f Update the example of using multiple buses to use DI's `bind`sc76b2c2 Uses the full service name when configuring the buses from the YAML configuration2409798 Middleware does not have a plurala20286d Add a note about the symfony serializer pack10f46eb Introduce the `TransportInterface`ef70bc0 Add a documentation about the middlewares3ff8cfe Add multiple buses configuration and type-hint examplea4bc592 Rename the adapters to transport
@nicolas-grekasnicolas-grekas deleted the messenger-transport branchMay 16, 2018 14:51
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@ycerutoycerutoyceruto left review comments

+3 more reviewers

@KocKocKoc left review comments

@srozesrozesroze approved these changes

@ogizanagiogizanagiogizanagi approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.1

Development

Successfully merging this pull request may close these issues.

7 participants

@nicolas-grekas@fabpot@sroze@Koc@yceruto@ogizanagi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp