🔥 message mod API improvements #439
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This variant is never constructed by us. When we encounter invalid field code, we throw an error.
Seriously doubt anyone uses this and this will also allow us to drop `FieldCode::Invalid` in the following commit.
A message with an invalid field code will just fail to deserialize so we don't need to represent this state.
Seriously doubt anyone uses this and this will also allow us to drop `message::Type::Invalid` in the following commit.
An invalid message will just fail to deserialize so we don't need to represent this state.
We'll be using these to avoid having to deserialize header and individual fields repeatedly.
As it is now based on the internal fields cache and doesn't involve deserializing the header.
We now construct the Header from fields cache and primary header clone.
This variant is never constructed anymore and hence useless. We could just deprecate it only but the chances of someone using this in client code are very low so let's not bother.
We now construct the fields from the cache.
They are not anymore.
Since we construct the fields from the cache.
Since we construct the header from the cache now.
Since we either construct the header from the cache now or deserialize from raw bytes and the deserialization will fail if the message has fields with incorrect codes (the only possible issue here).
They'll be deprecated in a following commit.
Not only is the performance of the direct fields getters no longer much worse than the getting the fields through the header, but also field getters on the header are much faster the that of Message. Moreover, I've ideas on how to make the header getter even faster.
I don't see users having much need for this and we're about to make `Field*` API private.
We don't need this method internally, doubt anyone uses it and we're about to turn Field* API private anyway.
We don't need this method internally, doubt anyone uses it and we're about to turn Field* API private anyway.
This exposes way too much internal details about the protocol that users do not need. The specific field getters we provide are sufficient for any low-level code. I wrote most of this when I was still very new to Rust and I started with a very bottoms-up approach. Hence we these API had been public until now. I doubt anyone uses these anyway so chances of people's code breaking are low but even if they do, it's a API breaking release.
|
For the record, @elmarco ack'ed in a private message. :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Many improvements to message module API, improving the ergonomics and performance.
Among other things, it drops/hides a lot of low-level API that IMO we should have never provided. In my defense, I was new to Rust when I wrote this code. :)
Zeeshan Ali Khan on behalf of MBition GmbH.
Provider Information.