-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Unify iteration approach #3386
Comments
I'm a big fan of the functional callback approach. |
Likewise, and it's more efficient (far less allocation) when we don't need to collect records in a list. |
Sounds like the actionable here is to unify around the callback approach. Maybe this is something @fedekunze or @sabau could pick up? |
Correct -- callback approach. /cc @aayushijain23 |
Agree on the callback approach, it's cleaner and more flexible |
I found now this issue (thanks @fedekunze ) I love the callback approach idea, was just thinking about the mixed naming I've found across the codebase Why not call all those callbacks
|
I don't think that reads well at all @sabau imho. Using |
Could work too, that's personal taste, I felt natural the phrase |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Going to through the staking code it's obvious that the way we choose to iterate across store records is totally inconsistent, sometimes we use a "retrieveAll" functionality which iterates and returns and array of all the records, which is then received and simply looped over. Other times we use an iterator function which takes an "operating function". Other times we a special keeper function which returns and
sdk.Iterator
which is then utilized in higher level function. There appears to be duplication of Iterators based on fulfilling thesdk.ValidatorSet
/sdk.DelegationSet
I'm not saying there isn't reason to have some variability in our iteration approach, it just seem that things need to be consolidated and re-evaluated as they've been slapped together.
I'm assuming that this also exists in other modules and should also be rectified.
The text was updated successfully, but these errors were encountered: