Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
With the current `repl` command, is easy to start the repl and load a contract given its address and ABI:
eth repl erc20@0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359
> .loadc erc20@0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359
But sometimes a contract has a related address which can be obtained with a state variable or method. In that case you have to load the first contract, consult the related address, and load the second contract (this can be done inside the repl with `loadc`, or you have to close the repl and open it again with the second contract).
It would be nice to have a easier way to do this.
### Option 1: Extend the repl command syntax
This would work like this:
eth repl myContract@0x123... myOtherContract@myContract.other
That is: the first contract has a variable (or view method without parameters) called `other` that returns an address, and `myOtherContract` is the ABI for that related contract.
While this could work, I have some concerns:
- I've been wanting to extend this "syntax" for a while, to allow the user to name the loaded contract. Something like `eth repl erc20@0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359:dai`. This potential new syntax and the one for related contracts are compatible, but I'm not sure about converting this into a sort of DSL.
- Sometimes the related address needs an argument. The obvious example is when you have an array with addresses. And while you could do something like `eth repl myContract@0x123... myOtherContract@myContract.others(0)`, I think that's going too far into the weird zone.
### Option 2: Make `.loadc` accept promises
My first alternative was something like (inside the repl):
.loadc myOtherContract myContract.methods.other().call()
This would solve the problem when the method that returns the address has parameters. The problem is that it's not arrow-up-able (a word I just made up and that means "you can't reuse the shell history easily"). Also, the `.loadc` syntax, like the one for `repl`, uses `@`, but I actually don't like that, so I'd be fine with using a plain whitespace instead.
### Option 3: Improve `conf`
This is not solving the described problem, but maybe it resolves the underlying problem: not wanting to remember and/or copy and paste a lot of addresses. If `conf` could be used for saving contracts addresses (and perhaps even address/ABI pairs, think `eth repl dai`), maybe that would be enough.
### Option 4: Save repl state
Alternatively, add a command that you can use to preserve variables between repl sessions. This would be useful for other things too, but I'm afraid that you couldn't really save contract instances because they are not serializable.