Skip to content
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

Merged
merged 5 commits into from
Dec 11, 2020
Merged

Fix namespace macro test #169

merged 5 commits into from
Dec 11, 2020

Conversation

maurolacy
Copy link
Contributor

@maurolacy maurolacy commented Dec 11, 2020

"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?
  • Maybe SnapshotNamespaces can be entirely removed (and SnapshotMap::new() takes the burden).
  • MEMBERS_CHECK -> MEMBERS_CHECKPOINTS?
  • MEMBERS_CHANGE -> MEMBERS_CHANGELOG?
  • Using &[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.

@maurolacy
Copy link
Contributor Author

maurolacy commented Dec 11, 2020

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 Vec<u8> (or even, String values) for names / stuff?

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.

@ethanfrey
Copy link
Member

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 &str rather than &[u8] for namespaces (In general in storage-plus). And the name changes make sense

Copy link
Member

@ethanfrey ethanfrey left a 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)

packages/storage-plus/src/snapshot.rs Outdated Show resolved Hide resolved
packages/cw4/src/query.rs Show resolved Hide resolved
@maurolacy
Copy link
Contributor Author

maurolacy commented Dec 11, 2020

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.

@maurolacy maurolacy merged commit 663a440 into master Dec 11, 2020
@maurolacy maurolacy deleted the fix-namespace-macro-test branch December 11, 2020 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants