Recommended contract object design about ethers.js HOT 5 CLOSED

Hey Nick!

I will create an issue for new... That has been on the back-burner, but I should certainly get that done sooner than later, and get an issue to track it.

Sounds like you are describing the Interface object, which already exists... It just isn't documented. I think it is currently accessible by the private variable SimpleStore._interface... It's private for now because I haven't fully finalized the API for accessing the various parts (the parser, formatter, et cetera), but I have now done enough with it, I should be able to finalize the return object, and publish it. And I can make a simple wrapper for Interface that works with any provider (I think it may already exist, just not exposed).

I will re-think through how provider, wallet and interface objects work together, because you are right, they are 3 separate things that should not entrench the use of the others.

Yeah, I should probably split out the various components as separate NPM projects, but would probably still keep them as one repo, what would you think of that?

The slew of unit tests (I think 30k-ish) for the encoder/decoder are designed strictly against it, so the rest of the wallet doesn't impact it. Also for the iOS implementation I've made all the test cases deterministic, so I will port that back to the JavaScript as well. It will make it easier for ethereumjs to pull them in too.

I was actually thinking of making the unit tests an independent NPM package too, so maybe having multiple NPM packages inside one repo will make that easier to maintain too.

I will get these changes made over the next few days.

Thanks! And please, more/all feedback is welcome. :)

from ethers.js.

Oh, actually, I'd like your feedback on one other issue... Functions can be overloaded by their signature. Currently, I drop all methods with the same method name after the first in the ABI.

contract Ugh {
    string _hello;
    function foo(uint64 bar) {
        _hello = "world";
    }

    function foo(int64 bar) {
        _hello = "WORLD";
    }
}

What should contract.setFoo(5) do? I'm thinking that it would create contract.setFooUint64 and contract.setFooInt64 and contract.setFoo would just point to the first in the ABI (uint64 in this case). So, sane people without signature overloading have a meaningful, working system, but insane people still have options. Or add an executeExplicit. that has everything spelled out (for the insane).

from ethers.js.

I think you shouldn't mess with anything. If there are two foo methods, that's already an extreme edge case. Just use and instantiate the first foo method. The other is ignored. Don't try and support the world and all of its possibilities.. it will crush you.

from ethers.js.

In my opinion it's not an edge case to have similarly named methods with different types. That's what overloading is for. My suggestion is don't make assumptions about executing the first method encountered, this may differ from what the EVM does. There is an EIP for it somewhere about typechecking and selecting an appropriate method. If an ABI is ordered differently from the EVM's choice a potentially different method will be run (even successfully if the type can be cast).

from ethers.js.

Closing this. The new 2.0 API has a way to create the deployment transaction.

from ethers.js.