This repository has been archived by the owner on Oct 19, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
It's more of a proposal, which i believe would ease things up when deploying from a ContractFactory.
Right now,
deploy()
seems to assume that theconstructor_args
passed are of the exact type that the constructor expects. So if one passesdeploy((1, "string".to_string()))
to a constructor that acceptsconstructor(uint256 a, string memory b)
, it will fail because it will tokenize1
asInt
instead ofUint
.This way, we maintain the method, but add a new one which receives an already ready
Vec<Token>
. Other libs have more freedom on doing their own parsing, and makes things easier if one requires to parse arguments from string. (eg. https://github.com/gakonst/foundry/blob/master/utils/src/lib.rs#L119-L125)Another option would be to bring over the code from the above link, taking
Vec<String
asconstructor_args
, and parsing it internally.Solution
Adds
pub fn deploy_tokens(params: Vec<Token>)
PR Checklist