Rename module generation structs for ModuleGen consistency
#1320
Conversation
| @@ -801,14 +799,14 @@ mod tests { | |||
| FakeFed::<Mint>::new( | |||
| 4, | |||
| |cfg, _db| async move { Ok(Mint::new(cfg.to_typed().unwrap())) }, | |||
| &ConfigGenParams::new().attach(MintConfigGenParams { | |||
| &ConfigGenParams::new().attach(MintGenParams { | |||
There was a problem hiding this comment.
These parameters are only used to generate config, not to generate the module instance itself. So keeping the Config part in the name might be reasonable. But I'd be ok with it for brevity.
There was a problem hiding this comment.
good point. Might be worth leaving as is. There is also the trait that should be renamed if we rename the struct.
impl ModuleConfigGenParams for MintGenParams { // previoulsy MintConfigGenParams
const MODULE_NAME: &'static str = "mint";
}So, I think it's usefull to keep config in the name then? @dpc
There was a problem hiding this comment.
Generating the config in a way is generating the module instance, at least from the higher level PoV.
"The module (instance)" is deterministically defined by the (type, config) tuple. (there's env, but it's more like injecting external connectivity runtime settings, so can be ignored).
So I think it's fair to say that "when we generate config, we generate the module".
Plus it's shorter. 🤷
There was a problem hiding this comment.
ok.
then the trait ModuleConfigGenParams should be renamed to ModuleGenParams, so we have a consistent impl ModuleGenParams for MintGenParams
There was a problem hiding this comment.
@mxz42 👍 I leave it up to you.
|
@mxz42 I've just noticed that mints |
folluw up for #1314 @dpc , also ACK @elsirion ?
Renaming the
MintConfigGenerationtoMintGenfor consistency withModuleGen.Same for
MintConfigGenerationParams->MintGenParams.same applies to the other modules.