Skip to content
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

[adapter][verifier] allow option and ID arguments in entry points #2149

Merged
merged 1 commit into from
May 24, 2022

Conversation

tnowacki
Copy link
Contributor

  • This seemed easy to fix so I gave it a shot, I think it fits in nicely but

    • I wish this wasn't so special cased. Could be interesting to have some system in the future to automagically allow certain types
    • I think the general solution here is probably public constructors.... but that is a long long ways off IMO
  • [Move] relax restrictions on allowed types in entrypoints #2049

  • Allow options of "pure" values

  • Allow ID as a "pure" value

  • As discussed on the issue, I don't think string is a good fit right here due to the complexities around validation

Copy link
Contributor

@lxfind lxfind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. This works. But I wonder how does someone actually pass them in when making a Move call.

@tnowacki
Copy link
Contributor Author

But I wonder how does someone actually pass them in when making a Move call.

A future PR... But it should be doable in the current CLI/builder
For ID, you can just pass an address.
For option, you should just be able to use a vector, either empty or a singleton

SignatureToken::StructInstantiation(idx, targs) => {
let resolved_struct = sui_verifier::resolve_struct(view, *idx);
// is option of a primitive
resolved_struct == RESOLVED_STD_OPTION
Copy link
Collaborator

@kchalkias kchalkias May 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will an Option<ID> work as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

@kchalkias
Copy link
Collaborator

Yes and when the other PR (that uses it in Move calls) is ready, we can change example contracts that previously did address casting to ID and were refactored not to use Option

type_params: type_args,
}) => {
let resolved_struct = (address, module.as_ident_str(), name.as_ident_str());
// is id or..
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this comment about?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is id or... is option of a primitive (down below)

Copy link
Collaborator

@kchalkias kchalkias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@sblackshear
Copy link
Collaborator

I do think passing an Option as an entrypoint argument is generally an anti-pattern (typically, it would be clearer to expose two different entrypoints instead), but I'm ok with supporting it.

@tnowacki
Copy link
Contributor Author

I do think passing an Option as an entrypoint argument is generally an anti-pattern (typically, it would be clearer to expose two different entrypoints instead), but I'm ok with supporting it.

Interesting, I hadn't considered that. What's the thought/worry here?

@tnowacki
Copy link
Contributor Author

I do think passing an Option as an entrypoint argument is generally an anti-pattern (typically, it would be clearer to expose two different entrypoints instead), but I'm ok with supporting it.

Interesting, I hadn't considered that. What's the thought/worry here?

@sblackshear, landing, but let me know the thoughts here or elsewhere

@tnowacki tnowacki merged commit 5c16252 into MystenLabs:main May 24, 2022
@tnowacki tnowacki deleted the option-n-stuff branch May 24, 2022 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants