-
Notifications
You must be signed in to change notification settings - Fork 354
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
Apply underscore pattern #993
Apply underscore pattern #993
Conversation
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.
Nice work on the proposal! I agree with most of it; however, I'm not sure on this one:
When the function name collides with a potential external implementation even when is not directly provided, to avoid potential confusion (e.g. _upgrade in the UpgradeableComponent or _pause in the PausableComponent).
You mean a function within an implementation, right? IMO it's unnecessary because accessing those functions in a contract need to include the component's state i.e.
fn pause(self: @ContractState) {
self.pausable.pause();
}
I don't think this will be harder for users to follow than self.pausable._pause()
It's not the worst thing if we keep this condition, but the less exceptions to the underscore convention, the better. Note that one could also argue that mint
and burn
, for example, could be functions in a contract as well (hence should be underscored). What are your thoughts?
I agree and will update accordingly. Thanks @andrew-fleming. BTW, I forgot to mention that this PR also changes the order of some functions in the internal implementation and is prioritizing not-underscored-functions in the order. |
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.
Most of the components look good with the changes! I left a few questions
As an aside, I think implementing #994 will further compliment this approach well
CHANGELOG.md
Outdated
- ERC721Component: | ||
- `_safe_transfer` function renamed to `safe_transfer` | ||
- `_safe_mint` function renamed to `safe_mint` | ||
- `_burn` function renamed to `burn` |
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.
Should we change _mint
to mint
since we're doing that with erc20?
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.
Similar to _transfer in ERC721, I think we should keep _mint underscored because we don't want users to use them, those are private helpers for the "safe" versions that are not underscored (safe_mint and safe_transfer)
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.
Similar to _transfer in ERC721, I think we should keep _mint underscored because we don't want users to use them
My impression was that we were taking an agnostic stance regarding x and safe_x because there's some risk in both approaches. They'll still be accessible and this is more of an organizational change, so it's not the end of the world if you prefer it this way. I'm just not a fan of blanket-favoring the safe variants
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.
mmm, that's a very good point. Agree.
src/token/erc721/erc721.cairo
Outdated
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.
Should _transfer
be transfer
in ERC721? The underscore is consistent with ERC20 though...idk. Thoughts?
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.
Also, should we make _upgrade
=> upgrade
in Upgrades?
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.
Should _transfer be transfer in ERC721? The underscore is consistent with ERC20 though...idk. Thoughts?
The answer is in the previous comment.
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 changed _update
to update
in ERC721 because we want users using that, for example, in the wizard, it is directly used to implement burn.
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.
We're almost there! I left a few comments
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.
We're missing _update
in the API
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.
And forgive me, I should have asked this before 😅 would it make sense to remove the underscore in _update
for erc20 and erc1155? It seems weird that we're only doing it with erc721. The rationale, as I see it with erc1155, is to promote update_with_acceptance_check
. I can get behind that if you want to keep it, but I'm not so sure with erc20. For consistency, we could just do update
across the tokens. WDYT?
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 think is ok to remove them.
|
||
[.contract-item] | ||
[[ERC721Component-_set_approval_for_all]] | ||
==== `[.contract-item-name]#++_set_approval_for_all++#++(ref self: ContractState, owner: ContractAddress, operator: ContractAddress, approved: bool)++` [.item-kind]#internal# | ||
[[ERC721Component-mint]] |
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.
We should switch mint
with transfer
to maintain the correct order
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 in the links section, since the order in the code is transfer before mint.
[[ERC721Component-update]] | ||
==== `[.contract-item-name]#++update++#++(ref self: ContractState, to: ContractAddress, token_id: u256, auth: ContractAddress)++` [.item-kind]#internal# |
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 should be between burn
and _owner_of
Co-authored-by: Andrew Fleming <fleming.andrew@protonmail.com>
…ericnordelo/cairo-contracts into feat/underscore-internal-functions-#795
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.
Final (non-blocking) suggestion: we should remove an underscore from the double-underscored erc20 and erc721 test names i.e. test__mint
, test__burn
, etc. Other than that, I think we're good to go!
…eat/underscore-internal-functions-#795
Fixes #795
The proposed pattern is the following:
PR Checklist