-
Notifications
You must be signed in to change notification settings - Fork 1
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
Enable generic type encoding via TypeResolver
and remove dependency on scale-info
#19
Changes from 1 commit
19b53b1
6c4b4ee
d1dfcf1
2a8369d
a727477
cdf624c
c4854a7
4126071
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,8 +17,8 @@ | |
|
||
/*! | ||
`parity-scale-codec` provides an `Encode` trait which allows types to SCALE encode themselves based on their shape. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. dq: Could we There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could; I think the only reason I don't do that is because the lib docs benefit from doc links ( There's almost certainly a tool somewhere though which takes the lib docs and copies them into a README for you, stripping such links! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It makes sense, the only crate I can think of might be: https://crates.io/crates/docify, something that substrate's been using for pallet docs |
||
This crate builds on this, and allows types to encode themselves based on [`scale_info`] type information. It | ||
exposes two traits: | ||
This crate builds on this, and allows types to encode themselves based on type information from a [`TypeResolver`] | ||
implementation (one such implementation being a `scale_info::PortableRegistry`). It exposes two traits: | ||
|
||
- An [`EncodeAsType`] trait which when implemented on some type, describes how it can be SCALE encoded | ||
with the help of a type ID and type registry describing the expected shape of the encoded bytes. | ||
|
@@ -164,7 +164,7 @@ pub mod ext { | |
} | ||
|
||
/// This trait signals that some static type can possibly be SCALE encoded given some | ||
/// `type_id` and [`PortableRegistry`] which dictates the expected encoding. | ||
/// `type_id` and a corresponding [`TypeResolver`] which tells us about the expected encoding. | ||
pub trait EncodeAsType { | ||
/// Given some `type_id`, `types`, a `context` and some output target for the SCALE encoded bytes, | ||
/// attempt to SCALE encode the current value into the type given by `type_id`. | ||
|
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.
dq: why do we need two readme's?
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.
The one in
/scale-encode
is the oen that is shown on crates.io for the crate, and the one at root is shown on github! This was the laziest way I could think of to make sure that they were kept in sync :)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.
you could just link to root/github README in the Cargo.toml of the crate but fine :)
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.
Yep, probably a symlink would work here to avoid some extra CI minutes :D
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.
That might not work because if the readme is outside of the crate it won't be uploaded with it, but I'd have to try it!
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.
Git does handle symlinks ok (as long as the FS supports it) though by the sounds of it (eg https://stackoverflow.com/questions/954560/how-does-git-handle-symbolic-links) (I'd assumed that it wouldn't!), so we could just make one readme be a symlink to the other, but I'm not too bothered either way given the CI check :)