Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
KERNEL is an 8-week, invite-only program for top tech talent looking to build relationships, products, and companies in blockchain and Web 3. 100 tal…
Aloha, Gitcoiners! How do you feel about Data Dignity, Quadratic Voting, Quadratic Finance and Decentralized Identity?
Type in [[ 2- term.length]] more characters to get results
[[ result.title ]]
[[ result.description | truncate(70) ]]
No matches found
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
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.