-
Notifications
You must be signed in to change notification settings - Fork 83
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
Feature/msg builders #972
Feature/msg builders #972
Conversation
f891840
to
4fc7631
Compare
Codecov Report
@@ Coverage Diff @@
## main #972 +/- ##
==========================================
- Coverage 29.76% 29.23% -0.54%
==========================================
Files 411 414 +3
Lines 26070 26246 +176
Branches 5315 5365 +50
==========================================
- Hits 7760 7672 -88
- Misses 16001 16263 +262
- Partials 2309 2311 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
Signed-off-by: Bogdan Mircea <[email protected]>
ac405d0
to
529f4f7
Compare
Signed-off-by: Bogdan Mircea <[email protected]>
0627947
to
b3ddc87
Compare
Signed-off-by: Bogdan Mircea <[email protected]>
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.
This is great! Looks a lot cleaner, much easier to read. Very nice 👍
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.
Love it! Makes message construction a breeze - so much easier on the eyes, the programmer is easily guided by the code completion now and I like that it is guaranteed that all mandatory fields are set at compile time 👍
Signed-off-by: Bogdan Mircea <[email protected]>
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.
Very epic! Cannot wait to use this
* Added builders for messages crate --------- Signed-off-by: Bogdan Mircea <[email protected]>
This PR introduces message builders through the
typed-builder
crate. The builder are based on the typestate pattern, but the crate is (at least advertised) to be fully compatible/replaceable by thederive-builder
trait, which is using runtime construction of the type and allows for more flexibility (like passing builders around).The
typestate
vsruntime construction
decision will essentially depend on whether consumers want/need to build messages themselves and how convoluted these processes usually get. We don't really have to decide now, but it's a good thing to consider in the future.For consistency reasons even some single fielded protocol specific messages contents implement builders, so that it is convenient, uniform and easy to know how one would go about composing a message.
There are some inner types which also implement the builders, yet for some types it is indeed quite the overkill (like
CredentialPreview
). I might revisit such types and just implement plain oldnew()
constructors.Another change that this PR brings is a uniformization of the
Invitation
message from theConnection
protocol, so that the same decorators are used regardless of invitation type. The rationale is that it's much easier to reason with the invitation this way and since the protocol is old and won't be suffering changes it should be fine to simply deal with it like this.Also, this addresses #949 .