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.
The CW-* examples are straightforwardly copied from the cw-plus repository, but they have a flaw - they all use the
Emptycustom msg (and query), which is not the best choice.The idea is that contracts/interfaces that use
Emptyare type-wise meant to be uploaded into the chains that do not useEmptymessages. 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