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

Make EntityMapper fallible #17197

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

cBournhonesque
Copy link
Contributor

Objective

Solution

Update the EntityMapper trait so that
map_entity(&mut self, entity: Entity) returns an Option<Entity> instead of Entity to account for cases where the mapping fails or cannot be done.

Testing

Updated the unit tests.
Maybe we should be using a Result, but I didn't know what to put in the error type. Maybe Box<dyn Error>?

Migration Guide

  • The map_entity method of the EntityMapper trait now returns an Option<Entity> instead of an Entity to support cases where the mapping fails. You will probably need to update any custom implementations of the MapEntities trait.

@cBournhonesque cBournhonesque added A-ECS Entities, components, systems, and events S-Needs-Review Needs reviewer attention (from anyone!) to move forward D-Trivial Nice and easy! A great choice to get started with Bevy labels Jan 6, 2025
@cBournhonesque cBournhonesque requested a review from Shatur January 6, 2025 20:19
@cBournhonesque cBournhonesque added the A-Networking Sending data between clients, servers and machines label Jan 6, 2025
Copy link
Contributor

@Shatur Shatur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After thinking about it a bit more, I think we always should replace the entity with Entity::PLACEHOLDER instead of keeping it untouched.
If yes, do we need to return Option?

@cBournhonesque
Copy link
Contributor Author

After thinking about it a bit more, I think we always should replace the entity with Entity::PLACEHOLDER instead of keeping it untouched. If yes, do we need to return Option?

So you're saying that you update MapEntities to return Entity::PLACEHOLDER if it fails,
and then you update EntityMapper to do something like:

    fn map_entities<M: EntityMapper>(&mut self, entity_mapper: &mut M) {
        let mapped = entity_mapper.map_entity(self.entity);
        if mapped != Entity::PLACEHOLDER {
            self.entity = mapped;
        }
    }

I think that works but it requires a bit of user-knowledge. It's kind of 'hidden' pattern that the user can remember to use Entity::PLACEHOLDER as an error value in both MapEntities and EntityMapper. I would probably prefer things to be more explicit.

@Shatur
Copy link
Contributor

Shatur commented Jan 6, 2025

So you're saying that you update MapEntities to return Entity::PLACEHOLDER if it fails, and then you update EntityMapper to do something like:

No, I suggesting to always assign the entity even if it's Entity::PLACEHOLDER. Like it was before:

    fn map_entities<M: EntityMapper>(&mut self, entity_mapper: &mut M) {
        self.entity = entity_mapper.map_entity(self.entity);
    }

It's just better then pointing to some random entity. So I suggesting to edit the map_entity implementation instead.

@cBournhonesque
Copy link
Contributor Author

So you're saying that you update MapEntities to return Entity::PLACEHOLDER if it fails, and then you update EntityMapper to do something like:

No, I suggesting to always assign the entity even if it's Entity::PLACEHOLDER. Like it was before:

    fn map_entities<M: EntityMapper>(&mut self, entity_mapper: &mut M) {
        self.entity = entity_mapper.map_entity(self.entity);
    }

It's just better then pointing to some random entity. So I suggesting to edit the map_entity implementation instead.

Ah I see; yes this works for my usecase!

@alice-i-cecile alice-i-cecile added D-Straightforward Simple bug fixes and API improvements, docs, test and examples and removed D-Trivial Nice and easy! A great choice to get started with Bevy labels Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events A-Networking Sending data between clients, servers and machines D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide a fallible map_entity api
3 participants