Implement LayoutFilter for Box<dyn LayoutFilter + Send> #290
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.
Added implementation of the
LayoutFilter
trait forBox<dyn LayoutFilter + Send>
.Description
impl LayoutFilter for Box<dyn LayoutFilter + Send> {...}
.Motivation and Context
When serializing a
World
, world- and entity serializers are passed toWorld::as_serializable()
by reference while the layout filter is passed by value - even thoughLayoutFilter::matches_layout()
does not consume the filter object. Because of that, when a user tried to develop a solution that will allow systems to request world serialization (that should be performed outside theSchedule
since systems do not have access to the wholeWorld
to do that) there was no way to store the desired layout filter in any type-agnostic way.This change allows storing layout filters inside
Box
es and later passing them "as is" toWorld::as_serializable()
without breaking the existing interface.In particular, this change solves the problem of decoupling the code that requests world serialization from the code that actually performs it, including the layout filter type. So now it's possible for different systems to store serialization requests (including custom layout filters) in
Resources
that will later be processed altogether outside theSchedule
execution.An additional
Send
requirement was added to allow to store filters inResources
accessed by systems that don't have to be thread-local.How Has This Been Tested?
I've tested these changes in my private project, but I've also added a corresponding example to the documentation (that, I suppose, could count as a doc-test).
Checklist: