Public items

[swfsql]

The sdk macro is mostly focused on trying to be as non-intrusive as possible, which I believe is an inclusive-focused decision, almost only and mostly generating the extern functions that are available on the compiled wasm binary.

This libraries diverges a little from that design decision, as there are some very useful properties that comes when generating public items, albeit the complexity increase from the user perspective.

One difference is that this library is almost entirely focused in appending information (inside modules) on the code. This is less surprising than to potentially erase otherwise expected information - although the sdk could also trivially change such behavior.

One main difference is the existence of the traits that represent the method calls, such as Serve and it's specialized versions, such as ServeRefMut, ServeOwned, etc. They enable (in relative terms) to easily redirect calls from extern entrypoints into the actual call logic. This in turn facilitates the separation of the "extern functions" creations from the "generation of various information about the contract".
This means that it's possible to define code that will be referred to when actually dealing with extern functions, and this makes it easier to define those codes without actually having to make any extern functions, which is advantageous for libraries.

Another advantage of having public items is that the definer of the trait can already define a request builder for it's own trait, and this can directly be used by users.
This means users don't need to hand-roll code that will represent the external contract - they can just use the builder defined by the target contract itself.
As the builder can statically prevent some forms of misusage, such as errouneously setting deposits while calling the method, this offers further potential advantages.

So this library already tends to make items public, but some further design iteration might be required, besides deciding what should be added as a public item or not.

• Request builders?
• Argument structures?
• Metadata?