Make ethabi-contract-derived functions more ergonomic to call.

[afck]

Functions generated with use_contract! (ethabi-contract/ethabi-derive) have a call method that takes a &Fn(Bytes) -> Result<Bytes, String>. It will pass the encoded function call into that callback, and decode its output. I'm clumsily using this to make extra-transaction calls: poa-ballot-stats:src/util.rs#L24.

I wonder whether it would make sense to include something like that in the web3 crate, to make it more convenient to use derived contracts' functions. Possibly it would be a method of Eth that takes a contract Address and returns a Box<&Fn(Bytes) -> Result<Bytes, String>>? (Or, thanks to Rust 1.26.0, even an impl Fn(Bytes) -> Result<Bytes, String>?) On the other hand, it should be more flexible than my workaround, and allow for transactions, too, i.e. specify an optional gas limit and price, from address, etc., so maybe it should use some builder pattern?

let callback = web3.eth()
    .raw_call_builder(contract_addr)
    .from(my_addr)
    .build();
contract.functions().my_function().call(my_param, &*callback)?;

Alternatively, it could just take a CallRequest, and internally replace its data field with the function's input. If CallRequest had a few convenience methods (or a builder), that could also be ergonomic:

let req = CallRequest::default().with_to(contract_addr).with_from(my_addr);
let callback = web3.eth().raw_call(req);
contract.functions().my_function().call(my_param, &*callback)?;

(Feel free to close this if it's a bad idea altogether.)

[tomusdrw]

Hi @afck! sorry for a late answer, that's definitely an awesome idea, we are working on a solution internally in Parity as well to figure that out. Static contract interface is also mentioned here: https://github.com/tomusdrw/rust-web3/issues/17, I'd love to integrate ethabi-derive directly to this project to make it super-easy and convenient to use.

Have a look at this PR as well: https://github.com/paritytech/ethabi/pull/85 it introduces a customizable return type of call so that the function can return not only Resutl<..> but rather a Future.

[afck]

Awesome, that contract! macro would be perfect!

And I wasn't aware of https://github.com/paritytech/ethabi/pull/85; I guess that also makes my suggestion obsolete. Or do you think it would make sense to add it anyway for now, since the ethabi change seems to take a long time?