move less important methods from Sysvar to SysvarSerialize

[kevinheavey]

Problem: the Sysvar trait relies on bincode, but most of the time people just want Sysvar::get which doesn't rely on bincode

Solution: make a SysvarGet trait that has one method: get. Make the Sysvar trait use SysvarGet::get. Annoyingly this is still technically a breaking change because we are adding a constraint to Sysvar, but for the vast majority of users nothing should break

Solution: move the other methods out of Sysvar and into a new SysvarSerialize trait

[febo]

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.

[kevinheavey]

Sounds like another PR to me

[febo]

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 solana-define-sysvar option, which in a way mimics the syscalls approach.

[kevinheavey]

The solana-define-sysvar approach is a bit awkward because of the orphan rule. We'd have to move the trait impls to the existing crates like solana-clock. But maybe that's pretty cheap once we have this lightweight SysvarGet trait

[febo]

The solana-define-sysvar approach is a bit awkward because of the orphan rule. We'd have to move the trait impls to the existing crates like solana-clock. But maybe that's pretty cheap once we have this lightweight SysvarGet trait

Yeah, the new trait is lightweight and the impl could be behind a feature on the individual crates.

[febo]

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.

[febo]

Maybe we should do this in a separate PR since we would need to modify the impl_sysvar_get macro implementation.

[febo]

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.

[kevinheavey]

I don't think the other methods on Sysvar belong in the same trait as get:

• 99% of use cases just need get
• even if bincode is replaced (which will take a while), there will still be a significant amount of code involved in implementing those methods

[febo]

I don't think the other methods on Sysvar belong in the same trait as get:

• 99% of use cases just need get
• even if bincode is replaced (which will take a while), there will still be a significant amount of code involved in implementing those methods

Agree. I should have been more specific when I said "refactor" Sysvar. I was thinking extracting the bincode related methods to a new trait and leave the get on the Sysvar. This will make it easier to eventually deprecate bincode without having to deprecate the Sysvar trait, which is a good trait name.

In other words, inverting the changes of the PR: the new SysvarGet stays as Sysvar and current Sysvar is renamed to SysvarSerialize/SysvarDeserialize (maybe a better name) with the bincode functionality.

[kevinheavey]

oh ok yeah makes sense

[github-actions]

If this PR represents a change to the sysvar layout, please open a follow-up PR to update the JavaScript client @solana/sysvars (example)
Thank you for keeping the JavaScript clients in sync with the Rust clients.

[github-actions]

If this PR represents a change to the sysvar layout, please open a follow-up PR to update the JavaScript client @solana/sysvars (example)
Thank you for keeping the JavaScript clients in sync with the Rust clients.