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
The CW-* examples are straightforwardly copied from the cw-plus repository, but they have a flaw - they all use the Empty custom msg (and query), which is not the best choice.
The idea is that contracts/interfaces that use Empty are type-wise meant to be uploaded into the chains that do not use Empty messages. They would work on other chains, as they do not send custom messages, so they do not cause invalid execution. Still, the same is true for any contract that produces an invalid custom message as long as it produces only variants supported by a particular chain.
The issue with this approach is testing - the MT environment is strongly typed, including the custom exec/query. It is its strength, not a weakness, and the best is to use it to enforce good programming practices instead of workarounds. The contract that is meant to be used on chains with not determined customs should be a contract that has generic customs - and that should be the default way of implementing contracts (and interfaces as well - those should, however, use associated types for generalization).
However, the examples we use do not show this practice - instead, they use Empty, disregarding the fact that one might want to use it as part of a wider testing environment with non-empty custom messages. They should all be changed to use the recommended way of building chains-agnostic contracts.
Interfaces
cw1
cw4
cw20-allowances
cw20-marketing
cw20-minting
whitelist
Contracts
cw1-subkeys
cw1-whitelist
cw20-base
The text was updated successfully, but these errors were encountered:
Part of #399.
This PR deals with the "Interfaces" part of the issue above.
It also makes the affected contracts and tests use `cosmwasm_std::Empty`
for their different implementations of the now generic interfaces.
Part of #399.
Makes generic the contracts cw1-whitelist and cw1-subkeys on the
examples. The latter depends on the former.
---------
Co-authored-by: Jan Woźniak <[email protected]>
The CW-* examples are straightforwardly copied from the cw-plus repository, but they have a flaw - they all use the
Empty
custom msg (and query), which is not the best choice.The idea is that contracts/interfaces that use
Empty
are type-wise meant to be uploaded into the chains that do not useEmpty
messages. They would work on other chains, as they do not send custom messages, so they do not cause invalid execution. Still, the same is true for any contract that produces an invalid custom message as long as it produces only variants supported by a particular chain.The issue with this approach is testing - the MT environment is strongly typed, including the custom exec/query. It is its strength, not a weakness, and the best is to use it to enforce good programming practices instead of workarounds. The contract that is meant to be used on chains with not determined customs should be a contract that has generic customs - and that should be the default way of implementing contracts (and interfaces as well - those should, however, use associated types for generalization).
However, the examples we use do not show this practice - instead, they use
Empty,
disregarding the fact that one might want to use it as part of a wider testing environment with non-empty custom messages. They should all be changed to use the recommended way of building chains-agnostic contracts.Interfaces
Contracts
The text was updated successfully, but these errors were encountered: