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

Add ERC721ABI, fix other ABIs #741

Closed

Conversation

andrew-fleming
Copy link
Collaborator

Fixes #739.

Copy link
Member

@ericnordelo ericnordelo left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Contributor

@martriay martriay left a comment

Choose a reason for hiding this comment

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

interfaces look good, are complete, and matching. but I thought the purpose of ABI traits was to offer a contract's (preset) full interface. we don't have a camel and a snake preset, we have a single preset using both interfaces (following the interface migration plan) and there should be a single ABI covering that. once we have more presets, each of them should have their own complete ABI.

as a side note, function order is inconsistent right now. I'd normalize function order between:

  • impl
  • ABI trait
  • docs

All of the above applies to other presets as well, not just 721

@martriay martriay linked an issue Sep 22, 2023 that may be closed by this pull request
@andrew-fleming
Copy link
Collaborator Author

This PR now includes the consolidated ABIs (with camelCase) for ERC20, ERC721, and Account. The ABIs include comments denoting the standard and non-standard whence they derive. The purpose of these comments is to:

  • Show the standards being implemented.
  • Make it easy to spot missing standards/methods.
  • Propose a normalized order as requested in Marto's comment above.

Let me know if you have objections to the function order
@martriay @ericnordelo

@andrew-fleming andrew-fleming changed the title Add ERC721ABI Add ERC721ABI, fix other ABIs Sep 23, 2023

* xref:#Account-\\__validate_deploy__[`++__validate_deploy__(self, hash, signature)++`]
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't validate_declare be here too?

Comment on lines +148 to +150
[#Account-Utilities]
==== Utilities

Copy link
Contributor

Choose a reason for hiding this comment

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

not sure if this is introduced in this PR or it comes from another, but i think we agreed on not having an Utilities section (not sure where, but maybe in the access PR)

Comment on lines +157 to +166
impl SRC6CamelOnlyImpl of interface::ISRC6CamelOnly<ContractState> {
fn isValidSignature(
self: @ContractState, hash: felt252, signature: Array<felt252>
) -> felt252 {
SRC6Impl::is_valid_signature(self, hash, signature)
}
}

#[external(v0)]
impl SRC5CamelImpl of ISRC5Camel<ContractState> {
Copy link
Contributor

Choose a reason for hiding this comment

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

hm why one is SRC6CamelOnlyImpl and the other SRC5CamelImpl? we should normalize these names

Copy link
Member

Choose a reason for hiding this comment

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

We are using CamelOnly when methods some are not added (having single-word function names), and just Camel, when all the methods are added (with the different casing).

// ISRC5
fn supports_interface(self: @TState, interface_id: felt252) -> bool;

// IDeclarer
Copy link
Contributor

Choose a reason for hiding this comment

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

is IDeclarer defined anywhere? if not let's put it with __validate_deploy__ as non-standard, I think it can be confusing otherwise.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's defined just above on line 24. I see your point though since it is non-standard. I'll move it to Non-standard to keep this simple

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'll move it to Non-standard to keep this simple

Actually, I take it back. I think there's value in identifying non-standard extensions by their interface when applicable. I vote we keep it

) -> felt252;
fn setPublicKey(ref self: TState, newPublicKey: felt252);
fn getPublicKey(self: @TState) -> felt252;
// Account Camel
Copy link
Contributor

@martriay martriay Sep 29, 2023

Choose a reason for hiding this comment

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

Suggested change
// Account Camel
// Camel case compatibility

not sure if it's worth adding a link to the interface migration docs. let's propagate whatever we decide to the equivalent comments in ERC20 and 721

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's probably not a bad idea to include a link. I'll add it and see what we think

@martriay martriay deleted the branch OpenZeppelin:cairo-2 September 29, 2023 17:12
@martriay martriay closed this Sep 29, 2023
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.

Add missing ERC721ABI trait
3 participants