-
-
Notifications
You must be signed in to change notification settings - Fork 723
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
Upgrade Message
To An Enum
#821
base: master
Are you sure you want to change the base?
Conversation
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.
Hi, and thanks for the PR! only a couple minor things left
Message { | ||
inner: protocol::Message::Pong(v.into()), | ||
} | ||
Message::Pong(v.into()) | ||
} | ||
|
||
/// Construct the default Close `Message`. | ||
pub fn close() -> Message { |
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'd just maintain the old behavior wdyt? You can close the socket without it being abruptly
reason: reason.into(), | ||
})), | ||
} | ||
Message::Close(code.into(), reason.into()) | ||
} | ||
|
||
/// Returns true if this message is a Text message. | ||
pub fn is_text(&self) -> bool { |
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.
on one side I'd just deprecate this old methods as one can just do matches!
now, what do you also think @seanmonstar ?
EDIT: ah but if we maintain then this PR doesn't introduce breaking changes..
Hello, I apologize for my procrastination. I know it isn't professional. I see that the pull request #903 has been made which does the same, is it the plan to close mine and merge the new one? If so shall I close mine or continue work? |
I saw the old documentation said something about upgrading this struct to a non exhaustive enum in the future, plus I prefer matching over something like this as an enum, so, I made it an enum.
This shouldn't cause any breaking changes as far as I'm aware. Someone could've wrote something like
let Message {..} = some_message;
, but really that has no practical use in any context, as such I highly doubt anyone wrote that in any production code.This should IMO improve usability of
Message
s by quite a lot.