contracts: generate ScVals from contract fn specs

[sreuland]

What problem does your feature solve?

Go SDK doesn't have capability to generate request parameter ScVals for a contract function defined on a contract spec.

What would you like to see?

Determine the best interface approach in SDK for DX concerns and provide the implementation of chosen approach.

• Option 1 - generate go code(bindings) for a given conract fn's. Applications follow a two step process.
  • step 1 - use a cli tool to generate code as bindings for a given contract and fn
  • step 2- integrate generated bindings code to application code.
  • prior poc for reference - Karthik/sep 48 event parsing #5806
• Option 2 - dynamic helper functions
  • New functional component added to contract package which provides ability for client to generate request parameter ScVals given a contract and a function name.
    • input - contract Wasm bytes or contract id/wasm hash for on-chain contract wasm code retrieval.
    • input - the contract fn name
    • input - list of parameter argument values expressed as go types to be applied as the args to the contract fn.
    • return - slice of ScVals in same order as the input parameters argument values
    • checkout the stellar-js-sdk Spec.funcArgsToScVals for a complete implementation reference.

What alternatives are there?

[leighmcculloch]

This functionality should probably be outside of support package I think in a top level contract package.

[leighmcculloch]

The JS SDK supports dynamic conversion of JS values to ScVals which makes sense for that environment because clients and interactions can be dynamically generated.

Go's environment is very different with most of the benefit will come from code generated clients rather than dynamic mapping from Go types to ScVals.

It sounds like what is proposed here would use reflection or something like that. Or is the is the intent to build a code generator to generate contract function builders?

The latter sounds more appropriate for Go and the use cases I think.

[sreuland]

This functionality should probably be outside of support package I think in a top level contract package.

Yes, that sounds better, i initially suggested support/contract to follow the pattern of existing support/contractevents . But this could do contracts and then a later tech debt would be to refactor support/contractevents under contracts/events instead.

[sreuland]

it sounds like what is proposed here would use reflection or something like that. Or is the is the intent to build a code generator to generate contract function builders?

Yes, I tried to limit the scope of this feature by implying a design towards functional helpers which application code uses rather than a code generator which implies 2 steps for application dev, one step to generate stub code and second step for application to use the generated stub code.

The scope here doesn't go into the low level design of how the functional helpers would work. There is complexity as reflection would be likely for the input parameters array or maybe the design here evaluates other abstractions for input parameter type conversions to scval representations.

The latter[code generation] sounds more appropriate for Go and the use cases I think.
Ok, the take away being the generated code would avoid a single tightly coupled type mapping conversion routine which could get pretty complex as more conversion cases are added. Whereas with the generated code, there would be similar functionality to inspect scval models from a spec but only generate one-off custom go structs or use existing primitive data type references for each contract fn parameter ScVal model.

I think the scope of this feature request can be expanded to include a front end design effort to confirm the functional or code-gen approach and which is considered best tradeoff?

[sreuland]

some prior exploration as poc from @karthikiyer56 - #5806

[mollykarcher]

Older related investigation: #5806