-
Notifications
You must be signed in to change notification settings - Fork 10
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
Refactor v13 metadata types #11
Conversation
about calls I think it might makes sense to still organize it as metadata V12. In the future we might want to add additional information per call variant. Like the origin the call can accept. Or just some unstructured information about the call. paritytech/polkadot-sdk#349 In this context having the call declared as a vec of function would allow use to just add another field in this FunctionMetadata. |
Makes sense, so for events and errors just the |
yes for me it makes sense considering those types are only description. But maybe opinion from other people using the metadata can be helpful here. |
TypeSpec
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.
looks good to me
Replace custom definitions for errors and event metadata with scale-info type information for the pallet
Event
andError
types (depends on paritytech/scale-info#87 which adds documentation to thescale-info
derive).As @thiolliere pointed out, metadata for events and errors (which are expanded to simple enums) can be captured already by the
scale_info
derives.Call definitions could also just use the
scale-info
derives on theCall
enum also, but we will keep the custom types in case we need to add additional metadata, see the comment below.Also: