Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
refactor(request-response): revise public API to follow naming convention #3159
refactor(request-response): revise public API to follow naming convention #3159
Changes from 1 commit
5ec3449
744c2fb
d0c69a8
bf3c663
abd326c
8dcf4b5
f5fcc29
6d998d4
3693a79
d2880cc
0e42929
00465e4
57bb47f
11ca1df
637a32d
dabd8bc
82c0e85
9813119
0b5eb4c
9be0603
84dd335
183f88d
1f3fbab
533ae05
223ec5f
12094b4
7cd250c
c030232
fb07b18
a613a94
6db0668
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Would just
Event
be pushing it too far? :DThere 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.
In case it isn't I think the
handler
module should be private so thisEvent
can't clash with the other one.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.
Intuitively
libp2p::request_response::handler::Event
reads better thanlibp2p::request_response::handler::HandlerEvent
and would be inline with the convention this pull request is enforcing.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.
yeah makes sense to me, thanks for the suggestion,
So, there is
request_response::Event
andrequest_response::handler::Event
now. Can you expand onEvent
's clashing Thomas?There will still be
request_response::RequestResponseHandlerEvent
which is deprecated and suggestsrequest_response::handler::Event
, if we makehandler
private how can we export both?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.
Yeah if we make
handler
private, we can no longer export it. What I meant with clashing is that from the outside, there is really only one event that is interesting for users and it is theNetworkBehaviour
'sOutEvent
.Given that we are already making this a breaking change, we might as well make
handler
private. In my opinion, no one should be depending on just theConnectionHandler
.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.
Thanks for the explanation Thomas.
Handler
andEvent
can't be private becauseNetworkBehaviour::ConnectionBehaviour
associated type needs to be public, and by consequenceConnectionHandler
's alsoThere 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.
Hmm that is news to me! We have a lot of protocols where the
ConnectionHandler
implementation is completely private to the crate. For exampleping
:rust-libp2p/protocols/ping/src/lib.rs
Line 45 in 5755942
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.
I just tested it locally and things compile if I make the
handler
module private. However, I'd suggest that we don't do this for now. I think together with #3159 (comment), we can make this completely non-breaking?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.
Thanks for digging this deeper Thomas! Did you understand what is it that with
request-response
that was making the compiler complain?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.
I think the issue is fairly subtle:
If you have a public type that implements a trait, the compiler enforces that the associated types also need to be public. It does however not check whether the type is within a public or private module in regards to the crate.
In our usecase, this means we can have a
pub struct Handler
that implementsConnectionHandler
but define it within a crate-private modulehandler
. This may or may not be a bug in Rust but I think one can argue that it makes sense:The API contract promised to the user is that
Behaviour
implementsNetworkBehaviour
.NetworkBehaviour
enforces thatNetworkBehaviour::ConnectionHandler
implementsIntoConnectionHandler
. The user can refer to this type as<Behaviour::ConnectionHandler as IntoConnectionHandler>
and call all public APIs on that. They don't need to know the concrete type that implements the functionality. This way, only the minimal promised API is actually exposed.