Override runMethod in version 5 Contract class

[naddison36]

I'm trying to extend Ethers to support Pantheon's private transactions. In order to do that I need to override the Contract class to call private transaction APIs instead of the tradition eth_sendRawTransaction and eth_call APIs.

I tried extending the Contract class and then overriding the constructor with a new runMethod function. See the v5 Contract class at https://github.com/ethers-io/ethers.js/blob/ethers-v5-beta/packages/contracts/src.ts/index.ts#L414

The problem is the super constructor needs to be called before other logic in the constructor of the extension class. This sets the callStatic and functions like properties. As these properties are readonly, they can't then be overridden in my constructor.

Here's my current failed attempt
https://github.com/naddison36/pantheon-ethers/blob/master/src/ts/privateContract.ts#L60

Being able to pass the runMethod in as an option function into the Contract constructor is one way to address this. Another is to make the runMethod function a static function on the Contract that can be overridden. But I'm open to other solutions.

[naddison36]

FYI, I copied the Contract class and added an optional runMethodOverride function to the constructor
https://github.com/naddison36/pantheon-ethers/blob/master/src/ts/contracts.ts#L451

This means I can now send contract calls as private transactions to Pantheon

[ricmoo]

Hmm. Would it make more sense to override the populateTransaction and sendTransaction in a subclass of AbstractSigner? That’s why more logic was moved there, so contracts can be a bit dumber since most chain-specific parameters are related to Signers and less so with Contracts...

[naddison36]

The problem I had was the signatures to populateTransaction and sendTransaction changed as I needed the extract privateFrom, privateTo and restriction parameters. I created new PrivateSigner and PrivateProvider interfaces. This meant the AbstractSigner abstraction broke down.

[ricmoo]

I'm planning to add a custom field to the Overrides type in the next minor bump, which I think will address the issues here. I don't know if there is a good way to expose the needed methods in a way that remains abstract. I am trying to avoid making these sorts of changes now on the v5 branch, so I can focus on v6, so I'm going to move this to discussions in case there is any further discussion to have. :)