New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add a toy example - rock's candy shop #2
Conversation
toys/rocks-candy-shop/Cargo.toml
Outdated
edition = "2018" | ||
|
||
[dependencies] | ||
sbor = { path = "/mnt/manygb/rock/dev/Radix/Scrypto/radixdlt-scrypto/radixdlt-scrypto/sbor" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should use relative path in this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Usually I do that but in this case my local version of the community-scrypto repo is housed in a very different place than the radixdlt-scrypto such that the relative paths don't make much sense. I was unsure how to proceed and decided that it was safer to do it this way for now. I made a note to add some soft links, if possible, to make the relative path approach work in the usual way for this code and after I do that then I will adjust this file accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. To make this work I had to add 6 soft links in the directory 3 levels up. Of course that included sbor, scrypto and radix-engine as referenced in the Cargo.toml file, but also required were soft links to sbor-derive, scryto-abi and scrypto-derive as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for providing this interesting example.
} | ||
let empty_bucket: Bucket = Bucket::new(RADIX_TOKEN); // canonical way to make an empty_bucket | ||
return empty_bucket | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting case where the bucket "type" is dynamic and sometimes the method doesn't even want to return a bucket.
I would consider returning an Option<Bucket>
, but this introduces complexity from an interface perspective.
struct CandyShop { | ||
// The different kinds of candies are kept here with each in a tuple | ||
// with a unique tag string that doubles as the candies' token symbol. | ||
candy_vaults: Vec<(String,Vault)> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would consider using a HashMap
or LazyMap
to make vault retrieval easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a separate example called Vending Machine that uses a HashMap of Vaults and so I think that I will leave this one as is just to show a different way to handle a requirement for dynamic Vaults. I will look into Option and fit that into an example somewhere as well. The empty_bucket approach shown is going to be a common idiom I would think simply because of it's simplicity.
This is my first non-trivial example for this community but not really ready for consideration as a main example.
The candy shop shows dynamically added vaults, returning a vector of buckets and some other useful stuff.
I included a list of things that people could do to extend this example.