JSON ABI types vs. Type string types

[davesque]

What was wrong?

The initial version of eth-abi was designed to accomodate basic types (types of the form <base><sub><arrlist> such as int256[2], fixed128x18 etc.

Later, support was added for tuples by extending eth-abi to handle type strings such as (int,int), (bool,(fixed,int))[] etc.

However, the problem with this approach is that most interaction with the ABI encoding format is done via information obtained from a JSON ABI specification for a contract. The JSON ABI represents tuple types entirely differently like the following:

{
  "type": "tuple",
  ...
  "components": [
    {"type": "int", ...}, {"type": "int", ...}
  ]
}

More information about the JSON ABI format can be found here: https://solidity.readthedocs.io/en/latest/abi-spec.html#json

Because of this, a number of utility functions were added to convert JSON ABI type information to type string representations. But this seems like a potentially unnecessary step. Ideally, we shouldn't have to use type strings as a kind of intermediate type format.

How can it be fixed?

One possible fix for this could be to convert or extend eth-abi to detect appropriate coders for a type based on a JSON ABI type description (instead of a type string). So a type registry could receive a dict object representing a JSON ABI type and produce the correct coder.

I'm not sure how hard this would be or if there are any problems with that approach that I'm not considering. But I wanted to make a note of it here in case we choose to take a look at it later.