-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Handle TriggerTargets that are combinations for components/entities #14563
Handle TriggerTargets that are combinations for components/entities #14563
Conversation
I'd like to see more docs explicitly explaining 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.
I had a similar change in the works that added impls for various combinations of (<entities>, <components>)
, but this is more general!
pub trait TriggerTargets { | ||
/// The components the trigger should target. | ||
fn components(&self) -> &[ComponentId]; | ||
fn components(&self) -> impl Iterator<Item = ComponentId> + Clone; | ||
|
||
/// The entities the trigger should target. | ||
fn entities(&self) -> &[Entity]; | ||
fn entities(&self) -> impl Iterator<Item = Entity>; | ||
} |
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.
Worth noting that this effectively reverts the change to this trait from #13991 which made it object-safe. I don't see any discussion for that original change, but if it's being changed back, it probably warrants some. At the very least, we should probably go back to the original impl ExactSizeIterator<...>
return types if possible to keep it consistent with 0.14.0
and minimize potential for breakage.
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.
Yes I was hoping to see more discussions on the consequences of this change; I wasn't sure why the change was made in the first place.
Note that impl ExactSizeIterator
is unfortunately not possible because calling chain
on 2 ExactSizeIterator
does not return an ExactSizeIterator
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.
We could also just provide our own Iterator
type to make this object safe
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.
After digging into #14775, returning Iterators would simplify its implementation. So I'm in favor of this change.
This should be independent from this PR I think, right? |
Kind of wondering if we shouldn't cut this from 0.15 for stability. |
Adopted in #16326 |
Objective
Solution
((A, B), (entity_1, entity_2))
as a trigger target, as well as the reverseTesting
The triggering rules for observers are quite confusing: