-
Notifications
You must be signed in to change notification settings - Fork 36
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 motoko whoami example #275
Conversation
Can't you just use the export function init(): Init {
installer = ic.caller();
} |
@tarek-eg We're wondering if |
@dansteren Make sure all of your examples have the same notices/licenses as the other examples. These are all derivative works with DFINITY licenses. |
It's not something built-in in motoko, but they provide a way to get the principal that installed the canister shared(msg) actor class Counter(init : Nat) {
// ... msg.caller ... === installer (owner)
} in shared functions shared(msg) func inc() : async () {
// ... msg.caller ...
} in rust you don't have the same but you can simulate that by storing the caller in init function which is effectively the installer. |
@tarek-eg thanks for pointing this out and breaking it down. I misunderstood when I was reading the motoko example and thought it was built into the language. Thanks for helping me to understand otherwise. I'll go back through and store the installer in the init message. |
@lastmjs these example have the notices/readmes already saved into directories in the codebase. So they're not showing up in the PR because they already exist. But I did double check and they're both there so we should be good. |
@lastmjs this is ready for review again. |
Additionally, there's something funky going on with messages on the init method. Motoko exposes a nice way to have them automatically carryover across canister upgrades. We should still consider implementing this behavior by automatically storing the installer, however, the same behavior can be achieved with a manual post-upgrade call, which is what we're doing here. It's just requires a little more work from devs. We should consider helping to improve this. See #271
Without initializing these variables there is a chance that they will be undefined when they are first referenced. This ensures that they are always a valid principal.
This helps show that the installer and argument are completely separate principals, and not related at all.
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.
Everything is looking really good, if we could just make that principal/address comment more correct
This implements the Motoko whoami example found here: https://github.com/dfinity/examples/tree/master/motoko/whoami.
I have tests for each method that the canister exposes.
The
installer
method cannot be implemented until #271 is resolved.One question I had was whether I should make the
idQuick
method aQuery
or anUpdate
. The motoko repo does not mark it as aQuery
but I think that was just an oversight on their part. Both codebases work as a query call. So, I'm not sure if I should assume that's what they meant, or strictly match them.Resolves #68