feat(sc): Improve ContractParam with fromJson

[snowypowers]

Rework how ContractParam construction works. Introduce fromJson and restructure the methods to have clear separation of logic. Static methods are now the preferred entry points with fromJson being the common entrypoint.

• Introduce ContractParamJson which is the direct json output coming from c#.
• Reduce constructor to type validation.
• Move parsing and transformation logic into static methods.
• Add fromJson method as a main entrypoint from external systems.
• Rework ContractParamLike to be a union of the class and json format.
• Add tests for parseEnum.

[snowypowers]

@ixje this pulls out the ContractParam changes from the SmartContract PR. Please take a look.

[ixje]

I find this a confusing remark, but that probably has to do with neon-js reversing byte arrays in many places I don't expect it to. For clarification purposes only; can you give the rules when neon-js does and does not expect a reversed hex string?

[snowypowers]

Usually it is big endian. In this case, a Hash160's value is parsed as bigendian on C# side while a ByteArray is not. But the rule of thumb in neon-js has always been to keep moving big endian around.

[ixje]

Sorry it is still ambiguous for me. What do you call big endian in this context? I ask this because the NEO C# team has this crazy idea that adding a hexadecimal prefix (0x) suddenly changes the endianness of the data. I couldn't blame you if you follow their convention, but because it deviates from the standard I'm still confused what it means

But the rule of thumb in neon-js has always been to keep moving big endian around.

Does this mean that you do not reverse Hash160/Hash256 types (UInt160/UInt256 in C#) but reverse everything else?

[snowypowers]

The reference case is usually the ByteArray used in C#. This is little-endian. So we extrapolate from this case to all other instances. Im mentioning the reversing because in NEO2, the convention was ContractParam.byteArray(reverseHex(getScriptHashFromAddress(address))).

In neon-js the 0x prefix is usually discarded. Im aware of the convention but currently not adopting it.

What is your definition of the standard?

[ixje]

What is your definition of the standard?

In general my definition is that the only time I care about endianness is when reading primitive types from a byte array where the primitive type is 2 or more bytes in size (e.g. short, int, long etc). Putting this in the NEO context and speaking from my Python project (which is a full port from C#), there are only 2 places in the whole code base where I reverse the data and they only happen for the UInt160 and UInt256 types.

• from string - taking a UInt160/UInt256 string representation produced by the C# code
• to string - making sure it produces the same string representation as the C# code (because many other tools expect this format)

Everything else internally can be said to be little endian. So my binary reader/writer classes read all data by default in little endian format. Which is why I previously mentioned that everything in neon-js seems to be in reversed format for me, because your representation seems to be big endian by default. :)

[ixje]

I mostly focused on feature completion. Having said that I noticed the following;

• hash256 - which I expect to be commonly used for contracts that wish to operation on a specific block or transaction.
  • has no static creation method
  • is not supported in the normal constructor
  • is not supported in fromJSON
• map - I actually don't expect any contract to use this over an array type. It's going to be more expensive to push the data for no gain other than maybe readability. Regardless, if we want to be complete then
  • the same 3 as hash256 apply here as well, additionally
  • is not supported in toJSON (this is known given the TODO in L: 352
• signature - never actually seen this used as a param, but for completeness
  • has no static creation method
  • is not supported in fromJSON
  • no explicit support in equals, although maybe the default case is sufficient?
• interop - I think we can ignore this. C# also doesn't support it in its own constructor, ToJson and FromJSON methods

[snowypowers]

I have added Hash256 support. I decided to drop Any, Map and Signature support for the moment since they are lesser used and im not too confident how they look like.

[ixje]

I have added Hash256 support. I decided to drop Any, Map and Signature support for the moment since they are lesser used and im not too confident how they look like.

I think that's a good call 👍