You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present, the constants.json file supports fundamental types like &'static str, u64, among others. However, it would be advantageous to enable the definition of complex types as constants, including addresses, to eliminate the need for frequent parsing during value retrieval.
For instance, consider the gas token address, which is currently represented as a string in constants.json and necessitates parsing every time a transaction hook is called. However, this might not be straightforward due to the context-dependent nature of addresses: their concrete implementation varies depending on the selected context, making them unavailable during module development because the runtime determines the context.
An alternative approach could be representing addresses as [u8; 32] in the constant definition. Since the compiler can optimize C::Address::from([u8; 32]), this would result in a transparent operation if the address' internal representation is equivalent to such an array (which is typically the case).
The text was updated successfully, but these errors were encountered:
At present, the
constants.json
file supports fundamental types like&'static str
,u64
, among others. However, it would be advantageous to enable the definition of complex types as constants, including addresses, to eliminate the need for frequent parsing during value retrieval.For instance, consider the gas token address, which is currently represented as a string in
constants.json
and necessitates parsing every time a transaction hook is called. However, this might not be straightforward due to the context-dependent nature of addresses: their concrete implementation varies depending on the selected context, making them unavailable during module development because the runtime determines the context.An alternative approach could be representing addresses as
[u8; 32]
in the constant definition. Since the compiler can optimizeC::Address::from([u8; 32])
, this would result in a transparent operation if the address' internal representation is equivalent to such an array (which is typically the case).The text was updated successfully, but these errors were encountered: