Avoid generating too much code in the (storage) macros

[tomusdrw]

Debugging code generated inside macros is really hard. We should try to implement generic structs outside of the macro code and then just implement a tiny bit of glue code (for instance trait implementation of the part that is instance-specific) inside the macro.

So instead of (

substrate/srml/support/procedural/src/storage/impls.rs

Line 139 in ed2faf4

impl<#traitinstance: #traittype> #scrate::storage::generator::StorageMap<#kty, #typ> for #name<#traitinstance> {

):

pub struct #name();
impl StorageMap for #name {
 ...(all the methods implementations)
}

we do something similar to:

struct #name_glue;
impl StorageItem for #name_glue {
  fn prefix() -> &'[u8];
}
pub type #name = StorageMap<#name_glue, #kty, #typ>;

[gui1117]

ah I missed this issue.

I think current trait generator are following this pattern,
StorageMap, StorageDoubleMap IterableStorageMap etc... Only requires a few item to be implemented, which are for StorageMap:

	/// Hasher. Used for generating final key.
	type Hasher: StorageHasher;

	/// Module prefix. Used for generating final key.
	fn module_prefix() -> &'static [u8];

	/// Storage prefix. Used for generating final key.
	fn storage_prefix() -> &'static [u8];

	/// Convert an optional value retrieved from storage to the type queried.
	fn from_optional_value_to_query(v: Option<V>) -> Self::Query;

	/// Convert a query to an optional value into storage.
	fn from_query_to_optional_value(v: Self::Query) -> Option<V>;

So maybe we can improve other aspect of code generation, I think storage macros are quite fine now.

[gui1117]

though we don't do the second suggestion totally as we curently do:

struct #name;
impl StorageItem for #name {
  fn prefix() -> &'[u8];
}

and we don't make use of name_glue and type defintion

[tomusdrw]

The idea with name_glue was to move the storage logic completely off the macro (so the only thing that stays there is just the prefix). The motivation was to make it easier to work on the logic (i.e. avoid getting in-macro errors).
Feel free to close the issue if you feel this is no longer relevant.

[shawntabrizi]

I think this can be closed?