Load "linked" contract in repl

[fvictorio]

With the current repl command, is easy to start the repl and load a contract given its address and ABI:

eth repl erc20@0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359
# or
eth repl
> .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.

[nicosampler]

I think a combination of 3 and 1 would be the best solution, if that is not possible I vote for 3 or 1.