-
Notifications
You must be signed in to change notification settings - Fork 668
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
refactor: add index
method for StacksEpochId
#5350
base: develop
Are you sure you want to change the base?
Conversation
This allows us to cleanup some magic numbers when accessing epochs in a list and make the expected behavior more clear to the reader.
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.
LGTM assuming CI passes
The list of epochs passed in here is not complete, so we cannot use the standard epoch indices for it.
There was once place acting on a list of epochs where the list was incomplete, so the standard indices shouldn't be used. This fix should resolve the failing tests. |
I think it'd be good to try to clean up the magic numbers and accessors used in epoch lists, but I'm kind of wary of encoding the indexes, even though it probably is perfectly safe (because there's no legal epoch ordering where An alternative that I think would have some of the same benefits would be a wrapper struct... pub struct EpochList (Vec<StacksEpoch>) And then defining: impl Index<&StacksEpochId> for EpochList {
type Output = StacksEpoch;
fn index(&self, index: &StacksEpochId) -> &StacksEpoch {
self.get(index).unwrap()
}
}
impl EpochList {
fn get(&self, index: &StacksEpochId) -> Option<&StacksEpoch> {
self.0.get(StacksEpoch::find_by_epoch_id(&self.0, index)?)
}
} Then, we could do things like |
Sure, that does seem nice. Likely a little slower, but I don't think we'd use it anywhere that is performance critical. |
Wrapper struct to make the accessing of the individual epochs easier and standardized.
Ok, re-refactored with |
stackslib/src/core/mod.rs
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.
Does it make sense to have the STACKS_EPOCHS_MAINNET
, _TESTNET
and _REGTEST
lazy statics be EpochList
s instead of arrays? Or would that generate way too many changes?
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.
Changed in e9c141f.
stacks-common/src/types/mod.rs
Outdated
/// Determine which epoch, if any, a given burnchain height falls into. | ||
pub fn epoch_id_at_height(&self, height: u64) -> Option<StacksEpochId> { | ||
for epoch in self.0.iter() { | ||
if epoch.start_height <= height && height < epoch.end_height { | ||
return Some(epoch.epoch_id); | ||
} | ||
} | ||
None | ||
} | ||
|
||
/// Determine which epoch, if any, a given burnchain height falls into. | ||
pub fn epoch_at_height(&self, height: u64) -> Option<StacksEpoch<L>> { | ||
for epoch in self.0.iter() { | ||
if epoch.start_height <= height && height < epoch.end_height { | ||
return Some(epoch.clone()); | ||
} | ||
} | ||
None | ||
} |
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 these should invoke StacksEpoch::find_epoch()
so that we avoid repeating the height searching logic.
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.
Done in e9c141f.
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 looks good to me-- it definitely improves the legibility of the epochs lists! Just a couple comments.
This allows us to cleanup some magic numbers when accessing epochs in a list and make the expected behavior more clear to the reader.