Querier generation #122
Querier generation #122
Conversation
Codecov Report
@@ Coverage Diff @@
## main #122 +/- ##
==========================================
+ Coverage 79.37% 79.96% +0.59%
==========================================
Files 30 32 +2
Lines 1624 1692 +68
==========================================
+ Hits 1289 1353 +64
- Misses 335 339 +4
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
One thing is missing here. In generated MT utilities, we add functions on Queries. I would say, that it would be beneficial to use Queriers in them instead of reusing already generated utilities (to reduce maintenance cost).
I like what is getting generated and how is used, but I don't like the implementation structure.
Unified mostly duplicated code
jawoznia
force-pushed
the
generate_querier
branch
from
637eac0
to
8b9419c
Compare
| } | ||
| } | ||
|
|
||
| pub struct MsgVariants<'a>(Vec<MsgVariant<'a>>); |
There was a problem hiding this comment.
I'm not sure if this is a good approach to generate Querier directly from MsgVariants.
Later (in #28 (comment)) when we will implement From on the BoundQuerier we will need to pass the interfaces to emit_querier or source and parse it there inside. It doesn't fit in new so this would be a double pass of source inside the MsgVariants.
We could introduce a new struct, f.e. ParsedInput or however we would call it that would hold all the attributes, messages, error type and so on. This would reduce the preparsing which we currently do in multiple places: multitest, EnumMessage, ContractEnumMessage.
This way we could use this struct (in some separate PR) in other Structs generating code and extract all the commons to be generated by the ParsedInput to avoid duplications and reduce maintanence cost.
There was a problem hiding this comment.
The thing is - whatever is generated able from msg variants itself should be generated from here so we do not expose fields. What you are mentioning is a matter of the responsibility split.
When you need to emit From implementation on BoundQuerier, you can do it in another, maybe a new type, as it does not need access to message variants (it needs only the modules where "forms" are implemented).
Same thing when you implement traits on queries - maybe you will need some additional data, but only for the impl block header, not for functions - you will be able to emit functions implementation from MsgVariants, which would be passed (by ref) to some additional structure, and then the this additional structure will generate inner implementation calling some Msgvariants emit-family function, and then it would add some context (like impl block itself).
| } | ||
| } | ||
|
|
||
| pub struct MsgVariants<'a>(Vec<MsgVariant<'a>>); |
There was a problem hiding this comment.
The thing is - whatever is generated able from msg variants itself should be generated from here so we do not expose fields. What you are mentioning is a matter of the responsibility split.
When you need to emit From implementation on BoundQuerier, you can do it in another, maybe a new type, as it does not need access to message variants (it needs only the modules where "forms" are implemented).
Same thing when you implement traits on queries - maybe you will need some additional data, but only for the impl block header, not for functions - you will be able to emit functions implementation from MsgVariants, which would be passed (by ref) to some additional structure, and then the this additional structure will generate inner implementation calling some Msgvariants emit-family function, and then it would add some context (like impl block itself).
PR2 of #28