Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Migrate account #616
Migrate account #616
Changes from 51 commits
c6996fa
387637e
90a7a4b
f66a988
e2d7248
52019ac
50b96bf
aae6451
4974643
c485e60
921e61f
fc2d995
f756504
ec321c0
27b0f7e
f2a43f5
7e5b91b
cbfb2dd
2b9cfd7
2111a20
bd5979e
995fadd
c2d4721
1b9b311
52357cc
c615ca3
cee8f05
d2ddedf
a65e1ef
2e859a4
d2219b6
fa14e09
c648eff
a10b46b
07225fb
c6e9d95
667bc0a
74c5452
c37f08a
3ea12ff
7de6a2e
025dd97
a3b0919
a034143
c24b3a5
43b19b0
e0664f1
e02e348
ec8620e
e8b19e6
3d8a6a5
649d36b
f51c1d7
4db1f2f
bce4724
c7e18db
b9c3051
d94c8b1
04ed19c
18f3cb5
27280f6
00b4110
98bf7ef
630e300
164b962
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
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.
now that we have better idea of how extensibility looks and thanks to the
#[internal]
annotation, i think we should remove the underscore to signal this is part of the module's APIThere 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.
The convention is not underscoring internal functions as in Solidity? What do you mean by this? Should we remove the underscore in the rest of the internals 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.
I'm curious about this as well. Perhaps, saving the underscore function only for internal functions that bear the same name would be appropriate e.g.
IMO it's a simple convention to follow. What do you guys think?
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.
according to our naming conventions, we use the underscore to signal a function's usage is discouraged. this is not the case for
assert_only_self
, which is ok to use. we should probably rework at least the categories (internal, external, public, private) to accommodate under Cairo 1.0Solidity's conventions didn't apply to Cairo 0.x, less to Cairo 1.0
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.
Agreed^
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.
Got it, but I don't think these naming conventions apply anymore for Cairo 1. Should we remove the underscore for
_execute_calls
as well, being this not a subset of the public API anymore (with the internal keyword) ? Should all the internal functions avoid underscore when possible? Like _mint in 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.
Agreed, but what rules are we applying in the meantime? Why should we remove the underscore for assert_only_self and not for other internal functions?
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.
are those internal functions meant to be used by users without special precaution? if so, it can be removed. e.g.
assert_only_self
is a modifier that can, and it's expected, to be used as is. whereas_mint
should be very carefully used since it lacks some invariant checks making it error prone, then we use the underscore. i believe this is addressed in our docs already.what i think we need to rework is the names of the categories (internal/external/private/public) because there's a new language environment, but i don't see any problem with the concepts behind the naming. any counter examples where the convention doesn't work anymore?