support for non primitive types

[eyalorbs]

As of now, there is no support for non primitive types on the sdk. It would a lot easier for a developer to write smart contracts if there was support for structs and other non primitive types.
In addition, the user cannot serialize structs or interfaces because it is not possible to write those types in the smart contract nor to import them from other libraries that the user may have created

[talkol]

I see two use cases:

1. Developer wants to store complex struct in state and then load it

2. Developer wants to receive complex struct as argument or return it in the result

I think (1) is more important

This should be implemented using a serialization library of some sort as part of the contract SDK

There are 3 main serialization candidates, we can support all 3:

1. JSON - developers understand it and like it, although some fuzziness regarding encoding of types like byte arrays, bigints and so forth. JSON doesn't have a good type schema, it's self descriptive with few types. JSON is also very wasteful and results in much larger state than needed (due to being textual for example).

2. membuffers - it's already a format we use for the Orbs protocol. The difficulty here is where to advertise the schemas. We can use reflection to do encoding/decoding and "understand" the schema from the provided type but this will have a performance penalty. Working without schema will make the API for developers very boilerplaty and hard to read.

3. Ethereum serialization protocol - will be nice to support it just for compatibility anyways. But it does rely on reflection to its performance is so so.

[talkol]

From a product perspective, what do you say about API like this:

type Person struct {
    Name string
    Age uint32
}

func someFunc() {

schema := "{Name: string, Age: uint32}"

var p Person
person := serializer.Decode(bytes, &p)

bytes := serializer.Encode(p)

The benefit here is that we have clearer expression of the schema for working across languages.. This is very similar to ABI btw.. so maybe just using Ethereum's approach would be good here and no need to do our own