[WIP] initial proof of concept for restricted env #21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@InquisitiveCoder
This is the approach I've had in mind for how to restrict which environment methods a given callback can use. Accomplished by adding a phantom type parameter to
RetroEnvironment
, and then one emptyenum
for each callback. Enum is used here to prevent a user from creating instances, an empty struct (struct LoadGame;
) could still be created withlet x = LoadGame;
.We then provide an impl for each
RetroEnvironment<Enum>
that just forwards the call along to the corresponding definition. This impl layer will be tedious, so I imagine we'll want a macro to do it for us:retro_env!(Global, get_core_assets_directory, get_content_directory)
.To make converting between the different phantom types easily, an associated method is provided called
into_state()
which exists on all instances ofRetroEnvironment<T>
.I see this approach being easy to follow, as you can just read the macro invocation to see which environment calls a particular callback has access to.
Let me know what you think!