You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment the return type of pallet_referenda::TracksInfo::tracks is a slice of tracks with a static lifetime, the trait is not very flexible as it only allows simple implementations where the tracks have to be hard-coded, relaxing this signature can open up new use cases like updating existing tracks without runtime upgrades(to avoid this) or a "dao pallet" that can create tracks on the fly and leverage the existing infrastructure provided by referenda.
In PR #2072 I propose returning an Iterator of Cow<'static, Track<_, _, _>>, it keeps compatibility with existing implementations that might want to keep defining tracks statically for performance reasons, it allows returning owned tracks that might come from the chain storage or a combination of both. An alternative of returning a Vec<Track>> is not ideal as it would still restrict us to less performant and more memory hungry implementations.
The text was updated successfully, but these errors were encountered:
At the moment the return type of
pallet_referenda::TracksInfo::tracks
is a slice of tracks with a static lifetime, the trait is not very flexible as it only allows simple implementations where the tracks have to be hard-coded, relaxing this signature can open up new use cases like updating existing tracks without runtime upgrades(to avoid this) or a "dao pallet" that can create tracks on the fly and leverage the existing infrastructure provided by referenda.In PR #2072 I propose returning an Iterator of
Cow<'static, Track<_, _, _>>
, it keeps compatibility with existing implementations that might want to keep defining tracks statically for performance reasons, it allows returning owned tracks that might come from the chain storage or a combination of both. An alternative of returning aVec<Track>>
is not ideal as it would still restrict us to less performant and more memory hungry implementations.The text was updated successfully, but these errors were encountered: