-
Notifications
You must be signed in to change notification settings - Fork 353
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
Fix namespace macro test #169
Conversation
Probably for another time and place, but: do we really want / need all those statically referenced slices? They are a pain to deal with. By example here, when you naïvely want to derive some names. I understand there are issues with not using references: Size not known at compile time, extra space / copies, mutability. Maybe others? But still. I know you've fought with this for a much longer time than me, and probably have a much clearer picture. So, I would very much like to hear a harangue supporting statically referenced slices everywhere. :-) Complementary to this, what are the disadvantages / associated complexities of using Finally, if we're gonna stick with statically referenced slices (and I want to stress that I'm OK with that, as I see at least some of their advantages) my opinion is that we just go ahead and define them when we need them. Even at the cost of some redundancy / verbosity. |
The reason I use such static slices is that I want to have a const constructor. This allows: pub const MEMBERS: SnapshotMap<&[u8], u64> =
SnapshotMap::new(snapshot_names!("members"), Strategy::EveryBlock); Before we had to use function constructors and they were a lot more verbose: const PREFIX_PERMISSIONS: &[u8] = b"permissions";
/// returns a bucket with all permissions (query by subkey)
pub fn permissions(storage: &mut dyn Storage) -> Bucket<Permissions> {
bucket(storage, PREFIX_PERMISSIONS)
}
/// returns a bucket with all permissionsk (query by subkey)
/// (read-only version for queries)
pub fn permissions_read(storage: &dyn Storage) -> ReadonlyBucket<Permissions> {
bucket_read(storage, PREFIX_PERMISSIONS)
} I really want to make the constructors super simple. And yes, we could use |
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 is more verbose, but you are correct, less confusing.
Can you remove the SnapshotNamespaces
entirely and just use three string arguments in new? Then I would call this good.
Also, I think updating all the namespaces in all the constructors in storage-plus
to accept &str
would be nice. We can still store &[u8]
internally (maybe change that later), but at least the constructor is simpler. (And &str.as_bytes()
is a const fn
so we can do this in a const constructor)
I'll create an issue for this, and do it after this one. Update: #170. |
"Fixing" the namespaces macro by removing it entirely, at the cost of two more (explicit) static strings.
Names can still be improved a little IMO, but I wanted to introduce as little changes as possible first.
SnapshotNamespaces
->SnapshotNames
?SnapshotNamespaces
can be entirely removed (andSnapshotMap::new()
takes the burden).MEMBERS_CHECK
->MEMBERS_CHECKPOINTS
?MEMBERS_CHANGE
->MEMBERS_CHANGELOG
?&[u8]
instead of&str
for consistency?Your call, but I think this is simpler, and clearer. At the cost of being a little bit more verbose.