Contract with function overloading

[marcelomorgado]

Hi,

A contract that I'm testing has different interfaces for same function name:

// Order that appers on ABI
initialize(string _name, string _symbol);
initialize(string _name, string _symbol, address _registry);
initialize(string _sender);
initialize();

I'm getting the error: Error: incorrect number of arguments when I'm trying call the second function.
Seems that when Contract is reading the ABI and it's only considering the first interface and ignoring the others.

ethers.js/src.ts/utils/interface.ts

Line 328 in c2ce59f

// Expose the first (and hopefully unique named function)

ethers.js/src.ts/contract.ts

Line 431 in 4425536

errors.warn('WARNING: Multiple definitions for ' + name);

Notes:

• I'm receving "WARNING: Multiple definitions" as well.
• With web3js I can call all of interfaces.

Thanks!

[ricmoo]

If you are using function overloading, the first definition gets the "bare" name. You will need to specify the specific function you wish to call, for example:

// initialize(string _name, string _symbol);
contract.initialize(name, symbol).then( ... );
contract["initialize(string,string)"](name, symbol).then( ... );

// initialize(string _name, string _symbol, address _registry);
contract["initialize(string,string,address)"](name, symbol, address).then( ... );

// initialize(string _sender);
contract["initialize(string)"](sender).then( ... );

// initialize();
contract["initialize()"]().then( ... );

You should be able to print contract.functions as well to get a list of all available functions, overloaded or otherwise.

This is more of a limitation of un-typed languages (well, any language which doesn't have at least the subset of types that Solidity has). Make sense? :)

[marcelomorgado]

Hi @ricmoo thanks for response,

1. contract.functions works and using your code I've was able to call them. Maybe it'll solve my specific problem. Thanks.

2. I'm not sure if is a javascript limitation because web3js works on the same scenario. In the case where we have two functions with the same name, the same number of params and different types, I agree with you, but itsn't the case.

I've written a sample contract with some test cases:

SampleContract.sol

pragma solidity ^0.5.0;

contract SampleContract {
  
  function overloading() public pure returns(uint) {
    return 1;
  }

  function overloading(string memory a) public pure returns(uint) {
    return 2;
  }

  function overloading(string memory a, string memory b) public pure returns(uint) {
    return 3;
  }
}

SampleContrat.test.js

describe.only("", () => {
    // OK
    it("should call overloading functions - web3js", async function() {
      const sampleContractWeb3 = new web3.eth.Contract(abi, address);

      const f1 = await sampleContractWeb3.methods.overloading().call();
      const f2 = await sampleContractWeb3.methods.overloading("a").call();
      const f3 = await sampleContractWeb3.methods.overloading("a", "b").call();

      expect(f1).to.equal("1");
      expect(f2).to.equal("2");
      expect(f3).to.equal("3");
    });

    // OK
    it("should call overloading functions - ethers", async function() {
      const provider = new ethers.providers.JsonRpcProvider();
      const sampleContractEthers = new ethers.Contract(address, abi, provider);

      const f1 = await sampleContractEthers["overloading()"]();
      const f2 = await sampleContractEthers["overloading(string)"]("a");
      const f3 = await sampleContractEthers["overloading(string,string)"](
        "a",
        "b"
      );

      expect(f1.toNumber()).to.equal(1);
      expect(f2.toNumber()).to.equal(2);
      expect(f3.toNumber()).to.equal(3);
    });

    // FAIL
    it("should call overloading functions - ethers", async function() {
      const provider = new ethers.providers.JsonRpcProvider();
      const sampleContractEthers = new ethers.Contract(address, abi, provider);

      const f1 = await sampleContractEthers.overloading();  // Error: incorrect number of arguments
      const f2 = await sampleContractEthers.overloading("a");
      const f3 = await sampleContractEthers.overloading("a", "b");

      expect(f1.toNumber()).to.equal(1);
      expect(f2.toNumber()).to.equal(2);
      expect(f3.toNumber()).to.equal(3);
    });
  });

Tests Output

> npx truffle test

Using network 'development'.



  Contract: SampleContract
    
      ✓ should call overloading functions - web3js (79ms)
WARNING: Multiple definitions for overloading
WARNING: Multiple definitions for overloading
      ✓ should call overloading functions - ethers (84ms)
WARNING: Multiple definitions for overloading
WARNING: Multiple definitions for overloading
      1) should call overloading functions - ethers
    > No events were emitted


  2 passing (240ms)
  1 failing

  1) Contract: SampleContract
       should call overloading functions - ethers:
     Error: incorrect number of arguments
      at Contract.overloading (node_modules/ethers/contract.js:130:19)
      at Context.<anonymous> (test/SampleContract.js:85:45)

"ethers": "^4.0.23",

[ricmoo]

So, there are certain cases which can be unambiguous, but that is mores the exception than the rule. A bigger problem comes when you wish to start passing overrides in, for example:

let overrides = {
    gasLimit: 100000
};
let response = contract.overloading(someValue, overrides);

In this case, it becomes more difficult to detect whether this is the 2-parameter signature with no overrides, or the 1-parameter signature with overrides. Type inspection can give you some additional non-ambiguous abilities, however, in the case that the second parameter to overloading were a tuple, you would be back in the same boat, since a struct Thing { uint256 gasLimit } could be a valid input to a contract.

So, rather than trying to guess, and sometimes being able to and other times not being able to, which would confuse the developer even more, I error on the side of non-ambiguity. In v5, overloaded operations will not be exposed. (correction: this only applies to ambiguous bare named overloaded operations; see below).

You can imagine things get more confusing when you have:

contract Foo {
    // In JavaScript a BigNumberish is the same regardless
    function bar(uint256 a) { }
    function bar(uint8 a) { }

    // In JavaScript, an address is a string...
    function bar(string a) { }
    function bar(address a) { }

    // In JavaScipt "0x12" could be a 4 character string, or a 1 byte array
    function bar(string a) { }
    function bar(bytes a) { }    
}

This is another area Web3 and I have disagreed on though. Guessing has often led to either significantly more code, or unexpected dapp security exploits though. :)

[marcelomorgado]

Oh, thanks for the explanation!
Got it. I think that isn't an issue from your side. I'll need to think more about my implementation.
Thanks.

[d14na]

You can imagine things get more confusing when you have...

@ricmoo I don't really feel as though the example you give in contract Foo is realistic. I have never seen a contract attempt to overload a function in this way (where you simple change the type of a param).

The example that @marcelomorgado gives in contract SampleContract where the number of params change is far more common. We have similar situations where we quite often offer 2 different versions of the same function, depending on who is calling owner or admin (admin will add the extra address _owner param).

FYI.. For a while now, I've noticed problems with the way web3js handles contracts in apps built with react(-native) and vue. Ethers.js has always "saved the day" (so really very grateful), but I'm worried about what this means In v5, overloaded operations will **not** be exposed. Will there still be a way to call overloaded function in v5?

Thanks!

Just want to add...

So, there are certain cases which can be unambiguous, but that is mores the exception than the rule.

as I mentioned above, I actually believe this to be the opposite, based on all the open-source solidity code I've read.

A bigger problem comes when you wish to start passing overrides in...

This seems to be the issue. Is there anyway to solve this with type casting, ie with TypeScript? I'm fairly new to TS, so I'm really not sure how that would work.

[ricmoo]

@d14na I have seen a few contracts that use overloading to accept different types of parameters during code audits. I agree it isn't common, but it is done, and would need to be handled. It is very confusing why something works in a bunch of cases, but in others it "just doesn't", and its because of an unrelated method to what you are dealing with having a name collision.

Oh! Totally sorry, I should have used a semi-colon in that sentence , it should read: "I error on the side of non-ambiguity; in v5, [ambiguous bare named] overloaded operations will not be exposed", i.e. only in the case of ambiguity. If there is only foobar(address), you can use contract.foobar(addr) or contract["foobar(address)"](addr). If there is foobar(address) and foobar(uint256), you would have to use contract["foobar(address)"](addr), there would be no contract.foobar (i.e. access by name).

Make sense? Sorry for the confusion. :)

There are ways to solve it, but they are all terrible, and some would fail for people using the JavaScript library directly without using TypeScript. I think this is the least terrible solution.

One suggestion being put forward is to expose "type indicator wrappers"... You could for example use contract.foobar(Uint256(value), Overrides({ gasPrice: 9000000000 })) vs contract.foobar(Address(addr)) for example, but that to me (at this point), seems alike a lot of extra typing and room for error for very little gained.

I'm always open to discussion though. :)

[d14na]

There are ways to solve it, but they are all terrible, and some would fail for people using the JavaScript library directly without using TypeScript. I think this is the least terrible solution.

I agree. I'm always annoyed when software fails "silently", because it leads to inconsistencies that are extremely hard to diagnose for the uninitiated.

I have 4 WARNINGS that appear each time I load a new (rather complex) contract i'm working on (which is what brought me here); but they couldn't bother me any less, I just wanted to make sure that Ethers would remain a viable option for such uses past v4, which you've confirmed. Thanks so much for creating an amazing alternative to Web3js.

Keep up the great work!

[ricmoo]

Thanks! Glad you enjoy it. :)

As a quick note, ethers.errors.setLogLevel(“error”) will silence those warnings if they do start to get on your nerves. :)

[PaulRBerg]

ethers.errors.setLogLevel(“error”) doesn't seem to be working in the beta version anymore. Using 5.0.0-beta.162.

[ricmoo]

Oh yes. Each library has its own logger in v5 and I haven’t added the global flag yet.

I’ll be adding it soon.