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

Turn MaskedStorage into a safe wrapper around UnprotectedStorage #664

Open
Rua opened this issue Dec 14, 2019 · 1 comment · May be fixed by #668
Open

Turn MaskedStorage into a safe wrapper around UnprotectedStorage #664

Rua opened this issue Dec 14, 2019 · 1 comment · May be fixed by #668

Comments

@Rua
Copy link

Rua commented Dec 14, 2019

At the moment, MaskedStorage requires a Component bound on its type parameter, and it's missing two of the methods that UnprotectedStorage offers. I think it would make the type more flexible, with relatively little work, if the following changes were made:

  • Remove the T: Component bound, instead adding a second type parameter S for the storage, with a S: UnprotectedStorage<T> bound.
  • Add the missing methods .get and .get_mut that forward to the corresponding UnprotectedStorage methods.

With these changes, the MaskedStorage type could be used for any T, anything that needs an ID for lookup would work, not just components. It would make it simply a safe wrapper around UnprotectedStorage. An example is Amethyst, which currently uses UnprotectedStorage for asset storage, but which has had to build its own safety wrappers. If MaskedStorage were changed in this way, users could use that type instead, without safety concerns.

@Rua Rua linked a pull request Jan 9, 2020 that will close this issue
@azriel91
Copy link
Member

Heya, I've had a skim through the code. I think the enabled flexibility is good. Would like to check out how much effort it is for consumers to migrate (it may be small -- I haven't read properly), and if it's small enough, would bundle it together with the other small improvements in the next release. Otherwise may decide to do a release, then put this one in the next release (that is, split the migration steps for consumers).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants