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

Observers should not use Entity::PLACEHOLDER #16029

Open
alice-i-cecile opened this issue Oct 20, 2024 · 7 comments
Open

Observers should not use Entity::PLACEHOLDER #16029

alice-i-cecile opened this issue Oct 20, 2024 · 7 comments
Labels
A-ECS Entities, components, systems, and events C-Code-Quality A section of code that is hard to understand or change C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!
Milestone

Comments

@alice-i-cecile
Copy link
Member

What problem does this solve or what need does it fill?

As described in the docs for Trigger::entity, observers can be triggered by a specific entity, or by no specific entity at all.

Rather than returning and storing an Option here, we use Entity::PLACEHOLDER.

This is unidiomatic and unclear, and makes it very hard to robustly handle this case.
In Rust, Option or other enums is the correct way to handle this, not special-cased values.

This is especially true since Option<Entity> is niched and doesn't even take up any additional memory.

What solution would you like?

Replace all uses of Entity::PLACEHOLDER in observers code with an Option<Entity>.

What alternative(s) have you considered?

We could use a custom enum here instead, but I think that an option is sufficiently clear.

Additional context

This was added as part of #10839

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Code-Quality A section of code that is hard to understand or change C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it! labels Oct 20, 2024
@alice-i-cecile
Copy link
Member Author

This was raised by @MiniaczQ here, who now regrets the end decision.

@alice-i-cecile
Copy link
Member Author

Related to #14236.

@alice-i-cecile alice-i-cecile added this to the 0.16 milestone Oct 20, 2024
@iiYese
Copy link
Contributor

iiYese commented Oct 20, 2024

We could alternatively canonicalize PLACEHOLDER as a null value for Entity.

@MiniaczQ
Copy link
Contributor

If it's niche optimized, I'd rather use Option<Entity>

@alice-i-cecile
Copy link
Member Author

We could alternatively canonicalize PLACEHOLDER as a null value for Entity.

I'd like to move away from this wherever possible.

@cart
Copy link
Member

cart commented Oct 21, 2024

I don't think Option<Entity> is the right approach here. Events (or whatever we choose to call them) should be designed with a specific target type in mind (no target, entity target, component target, etc).

Right after we landed observers I implemented "static event targets", which removes the need for Option / PLACEHOLDER , makes it statically impossible for users to try to access a non-existent entity for a "global event", and general prevents expressing the "wrong" thing.

https://github.com/cart/bevy/tree/static-event-targets

@alice-i-cecile
Copy link
Member Author

Sweet, I'm on board with that too.

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 C-Code-Quality A section of code that is hard to understand or change C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!
Projects
None yet
Development

No branches or pull requests

4 participants