-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Make the MapEntities trait generic over Mappers, and add a simpler EntityMapper #11428
Make the MapEntities trait generic over Mappers, and add a simpler EntityMapper #11428
Conversation
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.
An issue I have with this implementation is that everyone using MapEntities
will be forced to implement both methods, even though most of the time they will only use one of them.
I agree that this is not acceptable; there must be a better solution, maybe something like:
where Also I really don't like the names |
} | ||
|
||
/// Similar to `EntityMapper`, but does not allocate new [`Entity`] references in case we couldn't map the entity. | ||
pub struct SimpleEntityMapper<'m> { |
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.
It's never used inside Bevy, I would remove it and left its implementation to users.
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.
hm maybe
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.
Yeah I'm mostly not sure on why you would want this behavior. If that can be clearly demonstrated with docs (and tested) I'd be fine to ship it.
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.
That's the behaviour I'd prefer to have for networking, as I don't want/need the complexities associated with the existing EntityMapper. (Having to use EntityMapper::world_scope()
and needing access to &mut World
)
I will remove this from the PR as users can implement it themselves
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.
Sounds good. I'd happily accept a PR to add it with docs, but I agree, it can be split out from this.
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.
Left a couple of nits and suggestions :)
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.
LGTM once the SceneEntityMapper
rename is done and CI is green (duplicate dependencies can fail).
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.
Thank you a lot!
Just needs formatting now :) I'm going to merge this on Monday to leave time for other opinions to trickle in, but this should be in 0.13. |
Exciting! |
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.
Just some docs, looks good otherwise.
Co-authored-by: UkoeHB <37489173+UkoeHB@users.noreply.github.com>
Applied the last suggestion: I think it was a modest improvement. Merging now :) |
# Objective Fixes: #11549 Add a doctest example of what a custom implementation of an `EntityMapper` would look like. (need to wait until #11428 is merged) --------- Co-authored-by: Charles Bournhonesque <cbournhonesque@snapchat.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Hennadii Chernyshchyk <genaloner@gmail.com>
…tityMapper (bevyengine#11428) # Objective My motivation are to resolve some of the issues I describe in this [PR](bevyengine#11415): - not being able to easily mapping entities because the current EntityMapper requires `&mut World` access - not being able to create my own `EntityMapper` because some components (`Parent` or `Children`) do not provide any public way of modifying the inner entities This PR makes the `MapEntities` trait accept a generic type that implements `Mapper` to perform the mapping. This means we don't need to use `EntityMapper` to perform our mapping, we can use any type that implements `Mapper`. Basically this change is very similar to what `serde` does. Instead of specifying directly how to map entities for a given type, we have 2 distinct steps: - the user implements `MapEntities` to define how the type will be traversed and which `Entity`s will be mapped - the `Mapper` defines how the mapping is actually done This is similar to the distinction between `Serialize` (`MapEntities`) and `Serializer` (`Mapper`). This allows networking library to map entities without having to use the existing `EntityMapper` (which requires `&mut World` access and the use of `world_scope()`) ## Migration Guide - The existing `EntityMapper` (notably used to replicate `Scenes` across different `World`s) has been renamed to `SceneEntityMapper` - The `MapEntities` trait now works with a generic `EntityMapper` instead of the specific struct `EntityMapper`. Calls to `fn map_entities(&mut self, entity_mapper: &mut EntityMapper)` need to be updated to `fn map_entities<M: EntityMapper>(&mut self, entity_mapper: &mut M)` - The new trait `EntityMapper` has been added to the prelude --------- Co-authored-by: Charles Bournhonesque <cbournhonesque@snapchat.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: UkoeHB <37489173+UkoeHB@users.noreply.github.com>
# Objective Fixes: bevyengine#11549 Add a doctest example of what a custom implementation of an `EntityMapper` would look like. (need to wait until bevyengine#11428 is merged) --------- Co-authored-by: Charles Bournhonesque <cbournhonesque@snapchat.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Hennadii Chernyshchyk <genaloner@gmail.com>
Objective
My motivation are to resolve some of the issues I describe in this PR:
&mut World
accessEntityMapper
because some components (Parent
orChildren
) do not provide any public way of modifying the inner entitiesThis PR makes the
MapEntities
trait accept a generic type that implementsMapper
to perform the mapping.This means we don't need to use
EntityMapper
to perform our mapping, we can use any type that implementsMapper
. Basically this change is very similar to whatserde
does. Instead of specifying directly how to map entities for a given type, we have 2 distinct steps:MapEntities
to define how the type will be traversed and whichEntity
s will be mappedMapper
defines how the mapping is actually doneThis is similar to the distinction between
Serialize
(MapEntities
) andSerializer
(Mapper
).This allows networking library to map entities without having to use the existing
EntityMapper
(which requires&mut World
access and the use ofworld_scope()
)Migration Guide
The existing
EntityMapper
(notably used to replicateScenes
across differentWorld
s) has been renamed toSceneEntityMapper
The
MapEntities
trait now works with a genericEntityMapper
instead of the specific structEntityMapper
.Calls to
fn map_entities(&mut self, entity_mapper: &mut EntityMapper)
need to be updated tofn map_entities<M: EntityMapper>(&mut self, entity_mapper: &mut M)
The new trait
EntityMapper
has been added to the prelude