No funded issue found.
Check out the
Issue Explorer Be the OSS Funding you wish to see in the world.
Looking to fund some work? You can submit a new Funded Issue
Workers Auto Approve
Load "linked" contract in repl
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.
Setup your profile
Tell us a little about you:
No results found for
Type to search skills..
Required [[totalcharacter]] / 240
Are you currently looking for work?
[[ option.string ]]
Setup your profile
Our tools are based on the principles of earn (💰), learn (📖), and meet (💬).
Select the ones you are interested in. You can change it later in your settings.
I'm also an organization manager looking for a great community.
Enable your organization profile
Gitcoin products can help grow community around your brand. Create your tribe, events, and incentivize your community with bounties. Announce new and upcoming events using townsquare. Find top-quality hackers and fund them to work with you on a grant.
These are the organizations you own. If you don't see your organization here please be sure that information is public on your GitHub profile. Gitcoin will sync this information for you.
Select the products you are interested in:
Out of the box you will receive Tribes Lite for your organization. Please provide us with a contact email: