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 PMMR read methods into trait #3454
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.
Looks good. I think this makes a lot of sense, yes.
The whole ReadonlyPMMR
needs a rethink at some point - we still need mut
on a bunch of internal state and its not really readonly etc. (But that's for another PR).
Testing this locally now. |
What did you need here? |
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.
👍
{ | ||
type Item = T::E; | ||
|
||
fn get_hash(&self, pos: u64) -> Option<Hash> { |
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.
Actually - can get_hash()
and get_data()
(and similar) not also be moved to the trait if we had a backend()
fn?
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.
Yes, but that does mean we give access to the backend outside of the module. It might give use the temptation to accidentally use the backend directly.
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.
Hm on further thought, we could maybe add the backend()
function to a separate trait that isn't visible outside of the module..
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.
Turns out this is not really possible, as it would expose the private trait:
error[E0445]: restricted trait `core::pmmr::pmmr::PMMRBackend<B>` in public interface
So I'd rather keep it like it is, with some duplicate code.
|
PMMR
andReadOnlyPMMR
have a few common functions that are essentially duplicate code. I also needed access to one of thePMMR
functions on theReadOnlyPMMR
. This PR pulls these functions out of the specific impls and puts them in a common trait.