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:
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.
What was wrong?
The initial version of eth-abi was designed to accomodate basic types (types of the form
<base><sub><arrlist>such asint256[2],fixed128x18etc.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:
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.