Optimal event handling about hecs

[AngelOfSol]

I wonder if an API like the following makes sense:

impl World {
  fn handle_events<Event, F: FnMut(Q::Item), Q: Query, I: Iterator<Item=(Entity, Event)>>(&mut self, iterator: I, f: F);
  fn handle_events2<Event, F1: FnMut(Q1::Item), Q1: Query, F2: FnMut(Q2::Item), Q2: Query,I: Iterator<Item=(Entity, Event)>>(&mut self, iterator: I, f: F1, f2: F2);
 ...
}

You could probably do something with a Trait parameterized on tuples of queries?

trait EventHandler<Q, F, E> {
  fn handle_events(&mut self, iter: impl Iterator<Item=(Entity, E)>, f: F);
}

impl<Q: Query, U: Query, E> EventHandler<(Q, U), (FnMut(Event, Q::Item), FnMut(Event, U::Item)), E> for World {
  fn handle_events(&mut self, iter: impl Iterator<Item=(Entity, Event)>, f: F) { 
    // do stuff here...
  }
}

Really rough spitball here, but I think my point is there? (Not sure what Fn trait to use).

I'm just trying to come at it from the user side and figure out what would be nice to use.

[AngelOfSol]

Another idea I had that doesn't really necessarily optimize the problem on the backend, but might look ok for the user was something like this:

impl World {
  fn try_on_entity<T, Q: Query, F: FnOnce(Q) -> T>(&mut self, entity: Entity: f: F) -> Option<T> { ... }
}

[Ralith]

I wonder if an API like the following makes sense:

I think that could work, but the ergonomics of passing a bunch of queries in type parameters and then matching them up with a giant tuple of functions seem unpleasant enough to not be worth it.

Another idea

How does that differ from the existing World::query_one?

[AngelOfSol]

I think that could work, but the ergonomics of passing a bunch of queries in type parameters and then matching them up with a giant tuple of functions seem unpleasant enough to not be worth it.

I was hoping typeck could figure out the types for everything to make it so the client didn't have to figure it out themselves, or at least only have to annotate the function type parameters.

How does that differ from the existing World::query_one?

Same as above in regards to typeck. It's main use would be to reduce boilerplate by providing an Option::map like interface on the entity. At least that's what I was trying to get at.

[Ralith]

Type inference can't work backwards from an associated type.

[AngelOfSol]

That makes sense. I was hoping there was some way to decrease boilerplate a little bit. Either way I'm interested to see where this goes from the user-side, so I'll be watching.

[Ralith]

#154 is a closely related problem, where instead of cacheing a list of queries satisfied by an archetype, we want to cache a list of archetypes that satisfy a query.

[adamreichold]

I wonder if this use case isn't actually solved well by using the View types? I think the initial example could be rewritten as

let mut query_a = world.query::<A>();
let mut view_a = query_a.view();

let mut query_b = world.query::<B>();
let mut view_b = query_b.view();

for (entity, event) in events.drain(..) {
    if let Some(components) = view_a.get_mut(entity) {
        handle_a(event, components);
    }
    if let Some(components) = view_b.get_mut(entity) {
        handle_b(event, components);
    }
    // ...
}

which should be efficient?

[Ralith]

The idea here was to find a way to replace all the if let Some branching with indirection that could determine, based on the entity's archetype, exactly which of a collection of handlers should run without any dynamic filtering. I think the approach you've sketched would be a good enough substitute, since it all the nontrivial work out of the loop, but it's not generally applicable because it adds the constraint that A and B must be able to overlap without violating aliasing rules.