-
Notifications
You must be signed in to change notification settings - Fork 90
move less important methods from Sysvar to SysvarSerialize #87
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
base: master
Are you sure you want to change the base?
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.
This change is great! I wonder if we could take the opportunity of this breaking change to do a bigger refactoring. Ideally we should move the implementation of each sysvar to their own individual crate, instead of having all of them as a dependency on this one.
So solana-sysvar
has the trait definitions and macros only. What do you think?
Another alternative is to move the trait definitions and macros to a new crate (solana-define-sysvar
?), move the implementation to each individual sysvar crate and keep this one re-exporting everything to "minimize" the breaking change.
Sounds like another PR to me |
Yeah, definitely. I was mentioning to get an idea if this is an approach that makes sense. I am inclined to go for the |
f8d441d
to
2fbbbb2
Compare
The |
d7092fe
to
037682e
Compare
Yeah, the new trait is lightweight and the impl could be behind a feature on the individual crates. |
sysvar/src/lib.rs
Outdated
@@ -145,11 +142,24 @@ pub fn is_sysvar_id(id: &Pubkey) -> bool { | |||
ALL_IDS.iter().any(|key| key == id) | |||
} | |||
|
|||
/// Interface for loading a sysvar. | |||
pub trait SysvarGet: Default + Sized { |
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 removed the requirement for the Default
trait in pinocchio, so I wonder if we should do the same here as well. Individual sysvars could still implement Default
when applicable.
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.
Maybe we should do this in a separate PR since we would need to modify the impl_sysvar_get
macro implementation.
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.
Overall the approach is an improvement over the current bincode
requirement for Sysvar
, but I wonder whether it would be better to refactor the whole Sysvar
trait instead of creating a new trait. We should stop using bincode
anyway, so we could just get rid of that.
I don't think the other methods on
|
Agree. I should have been more specific when I said "refactor" In other words, inverting the changes of the PR: the new |
oh ok yeah makes sense |
If this PR represents a change to the sysvar layout, please open a follow-up PR to update the JavaScript client |
If this PR represents a change to the sysvar layout, please open a follow-up PR to update the JavaScript client |
Problem: the Sysvar trait relies on bincode, but most of the time people just want
Sysvar::get
which doesn't rely on bincodeSolution: make aSysvarGet
trait that has one method:get
. Make theSysvar
trait useSysvarGet::get
. Annoyingly this is still technically a breaking change because we are adding a constraint toSysvar
, but for the vast majority of users nothing should breakSolution: move the other methods out of
Sysvar
and into a newSysvarSerialize
trait