factor out SysvarGet from Sysvar

[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

[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.