xclud / web3dart

Ethereum library, written in Dart.
https://pub.dev/packages/web3dart
MIT License
170 stars 94 forks source link

Functions with Different Paramaters throws error #49

Open TheGreatAxios opened 2 years ago

TheGreatAxios commented 2 years ago

I am looking to encode a function call to make something more dynamic than using the generated contracts. In this case, the ERC-721 standard contains two safeTransferFrom calls; one with data as a 4th param and one without. The library throws because:


    try {
      ContractFunction _function = functions.singleWhere((f) => f.name == name);
      return _function;
    } catch (err, trace) {
      print("Error: $err\n$trace");
      rethrow;
    }
  }```

However, if this code is replaced with 

```ContractFunction function(String name) {
    try {
      ContractFunction _function = functions.firstWhere((f) => f.name == name);
      return _function;
    } catch (err, trace) {
      print("Error: $err\n$trace");
      rethrow;
    }
  }```

  Then it will take the first function that matches. This is my temporary hack since I know it will work with the only contracts I am supporting, however, for long term support; a secondary parameter should be optional that is the length of the number of params. Generally, the use of same name functions is not recommended in general; however, you cannot argue with OpenZeppelin. 

Therefore, this solution will enable you to pass in the number of params expected for a function that will be default by ignored. 

I will make a PR request at some point however, I need to check the differences. Currently, my repo is quite different than the original due to the original owner (no disrespect, the core library is great); never merging any of my suggestions. 

Additionally, while I do not have a dedicated server for this, if anyone that comes across this needs support you can join my Discord server and ping me in the #developers channel for greater response time. 

Ultimately, I will try to fix and merge all of the PRs, however, @xclud I believe we should consider starting from scratch.