-
Notifications
You must be signed in to change notification settings - Fork 957
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
swarm/handler: Rename InEvent
and OutEvent
to FromBehaviour
and ToBehaviour
#2854
Comments
InEvent
and OutEvent
to FromBehaviour
and `ToBehaviourInEvent
and OutEvent
to FromBehaviour
and ToBehaviour
I find this more intuitive looking at |
We can name that one |
+1 in favor of using more concrete names for associated types. Maybe we could instead of |
Related to this: What do you think about renaming When first working with |
Same! Especially the |
With #2867
I suggest we do the same change on |
I am in favor of the proposals in this issue. |
Yes, I think that makes sense. The only weird part is that
I suggest we try and pack all of these into a single release. |
I'd be in favor of this. |
Being the rename of the associated types a breaking change by itself, should it be addressed when we soft (#3011/#3085) or hard deprecate the |
Good point @jxs. Doing the rename with the hard deprecation (i.e. removal) of the |
Sounds reasonable to me. +1 |
I'm confused about why we keep saying |
Planning this for the next milestone. |
Previously, the associated types on `NetworkBehaviour` and `ConnectionHandler` carried generic names like `InEvent` and `OutEvent`. These names are _correct_ in that `OutEvent`s are passed out and `InEvent`s are passed in but they don't help users understand how these types are used. In theory, a `ConnectionHandler` could be used separately from `NetworkBehaviour`s but that is highly unlikely. Thus, we rename these associated types to indicate, where the message is going to be sent to: - `NetworkBehaviour::OutEvent` is renamed to `ToSwarm`: It describes the message(s) a `NetworkBehaviour` can emit to the `Swarm`. The user is going to receive those in `SwarmEvent::Behaviour`. - `ConnectionHandler::InEvent` is renamed to `FromBehaviour`: It describes the message(s) a `ConnectionHandler` can receive from its behaviour via `ConnectionHandler::on_swarm_event`. The `NetworkBehaviour` can send it via the `ToSwarm::NotifyHandler` command. - `ConnectionHandler::OutEvent` is renamed to `ToBehaviour`: It describes the message(s) a `ConnectionHandler` can send back to the behaviour via the now also renamed `ConnectionHandlerEvent::NotifyBehaviour` (previously `ConnectionHandlerEvent::Custom`) Resolves: #2854. Pull-Request: #3848.
Previously, the associated types on `NetworkBehaviour` and `ConnectionHandler` carried generic names like `InEvent` and `OutEvent`. These names are _correct_ in that `OutEvent`s are passed out and `InEvent`s are passed in but they don't help users understand how these types are used. In theory, a `ConnectionHandler` could be used separately from `NetworkBehaviour`s but that is highly unlikely. Thus, we rename these associated types to indicate, where the message is going to be sent to: - `NetworkBehaviour::OutEvent` is renamed to `ToSwarm`: It describes the message(s) a `NetworkBehaviour` can emit to the `Swarm`. The user is going to receive those in `SwarmEvent::Behaviour`. - `ConnectionHandler::InEvent` is renamed to `FromBehaviour`: It describes the message(s) a `ConnectionHandler` can receive from its behaviour via `ConnectionHandler::on_swarm_event`. The `NetworkBehaviour` can send it via the `ToSwarm::NotifyHandler` command. - `ConnectionHandler::OutEvent` is renamed to `ToBehaviour`: It describes the message(s) a `ConnectionHandler` can send back to the behaviour via the now also renamed `ConnectionHandlerEvent::NotifyBehaviour` (previously `ConnectionHandlerEvent::Custom`) Resolves: libp2p#2854. Pull-Request: libp2p#3848.
Description
Rename the associated types of
ConnectionHandler
fromInEvent
toFromBehaviour
andOutEvent
toToBehaviour
.Motivation
Using a
ConnectionHandler
outside of theNetworkBehaviour
abstraction is generally possible put very unlikely. To make it easier for users to understand, what these types do, we can rename them to not just be an "in" and "out" but to include where the event is going to be handled or where it is coming from.Current Implementation
Are you planning to do it yourself in a pull request?
Maybe.
The text was updated successfully, but these errors were encountered: