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
AccountType
, addEthImplicitAccount
#14AccountType
, addEthImplicitAccount
#14Changes from 1 commit
08da7d8
d3b440e
07bf40f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 would look like a breaking change for near-account-id crate, so I would just return
true
here from the get-go. Any strong objections? It would be a separate challenge for the future if NEAR Protocol changes account-id rules drastically.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.
Ok, I can get around that within the nearcore repo, to keep this repo stable. @wacban wdyt? There are few places in the
nearcore
repo where we callis_implicit
, so I can replace them withget_account_type() == NearImplicit
and mark as TODO to change it back in the next PR.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.
SGTM
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 still need to work out what to do about the existing named accounts that have the eth account format. I would still go ahead with this PR as agreed because it's blocking everything elsewhere.
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.
What is the motivation for this extra enum? I feel that
is_eth_implicit
andis_near_implicit
+is_implicit
would be enough.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.
@frol please see the links in the pr description for more details about this project
The reason for using an enum here is good software development practice. We want to be explicit about the different types of accounts and force ourselves and future developers to be aware and correctly handle the different types of account. Additionally this is more future proof if we ever need to add more account types. This was also discussed on the original PR in nearcore.
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.
If that is the intent, we should remove the
is_near_implicit
andis_eth_implicit
methods from the AccountIdRef type as having two different ways to do the same thing is not helping here and does not really force users to handle all the cases.Just for the future reference, I will link the prior discussion: near/nearcore#9969 (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.
P.S. Given that "renaming"
is_implicit
tois_near_implicit
is already a breaking change, removing all thoseis*implicit
methods might be just fine.Just to model the usage here:
BEFORE
AFTER renaming to
is_near_implicit
and naive (most probably invalid, right?) changes:AFTER if no
is_*implicit
methods:OR
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.
@frol Would it be ok if I just rename
pub fn is_eth_implicit
tofn is_eth_implicit
andpub fn is_near_implicit
tofn is_near_implicit
? I would remove docstrings with tests fromis_eth_implicit
andis_near_implicit
, and add corresponding docstring with tests forget_account_type
.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.
@staffik Do you mean removing
pub
fromis_eth_implicit
andis_near_implicit
? I would consider moving them tovalidation.rs
fileThere 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.
@frol Yes. Sure, I will try to move them to
validation.rs
file.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 would consider keeping
is_implicit
(=is_near_implicit || is_eth_implicit
) to denote that account does not need to be created explicitly withCreateAccount
action. What do you 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.
Please see the original pr for more details.
TLDR - we want to be explicit about type different types of implicit account. In order to not impede developer productivity we are adding the is_implict method to the account type enum so it is still reasonably convenient to use while making developers aware of the different account types.