Added multiple callback logic to event_listener

[av1roytman]

This is a work in progress, just wanted to get some of the code out there as we are working on it.

Closes #21

[alice-i-cecile]

This comment is outdated.

[alice-i-cecile]

This comment implies that it returns Self, but instead the method mutates.

[alice-i-cecile]

This should be a constructor.

[alice-i-cecile]

These derives need to be manually implemented; phantom data doesn't play nice, since it looks at the bounds for E, even though PhantomData always fulfills the bounds.

[alice-i-cecile]

We should revert the changes to the method signatures from here down. Rather than mutating self, create a new empty event listener, mutate and then return it.

[alice-i-cecile]

This should not take &mut self either: create a new empty event listener first.

[alice-i-cecile]

ListenerId would be clearer.

[alice-i-cecile]

We need a way to get the callback handles out of the event listeners.

We should add:

1. Methods to iterate over all the callbacks.
2. Return the generated ids whenever callbacks are added. add_command does this, but others don't.

[alice-i-cecile]

Consider using an atomically incremented identifier here instead.

[alice-i-cecile]

This should now remove and return all stored systems and their IDs.

[alice-i-cecile]

This would be clearer if renamed to remove_all.

You can keep take around as a function, and add a deprecation warning.

[alice-i-cecile]

ListenerHandle no longer exists :)

[aevyrie]

Here is a sketch of what the API could look like:

// In the simplest case, you can add a listener with no callbacks in a bundle
commands.spawn((Name::new("Foo"), On::<Click>::default()));

// Option 2 is to create a listener with callbacks ahead of time, and insert that
// Create an empty listener
let mut bar_listener = On::<Click>::default();
// Add callbacks to it via `Commands`, and return the id of the callback you just added
let callback_1 = commands.add_callback(bar_listener, || info!("hello from a callback 1"));
// Repeat as many times as you'd like
let callback_2 = commands.add_callback(bar_listener, || info!("hello from a callback 2"));
// Add the listener, which now has two callbacks, to a new entity:
commands.spawn((Name::new("Bar"), bar_listener));

// Option 3 is to add to an existing listener which you got from a query or similar
// Create an empty listener
let mut baz_listener = my_query.single_mut();
// Same API as above: we have mutable access to the listener, so we can add callbacks to it
let callback_3 = commands.add_callback(baz_listener, || info!("hello from a callback 3"));

// Note that commands.add_callback() could be provided in a few ways:
// same as above:       Commands::add_callback(&mut self, listener: &mut On<E>) -> ListenerId
// on the listener:     On::<E>::add_callback(&mut self, &mut World) -> ListenerId

// Because `add_callback` returns the id, you can then use it to remove or replace callbacks
let callback_id = commands.add_callback(listener, || info!("hello world"));
commands.remove_callback(listener, callback_id); // also despawns the callback entity
commands.replace_callback(listener, callback_id, || info!("a new callback"));

[aevyrie]

From discord discussion, a rough look at what the new method will look like:

#[derive(Component, Default)]
pub struct On<E: EntityEvent> {
    phantom: PhantomData<E>,
    /// A function that is called when the event listener is triggered.
    pub(crate) callbacks: Hashmap<ListenerId, CallbackSystem>,
}

struct ListenerId(Entity);

impl<E: EntityEvent> On<E> {
    fn add_callback(&mut self, commands: &mut Commands, callback: impl IntoSystem<(), (), Marker>) -> ListenerId {
        let id = ListenerId(commands.spawn_empty());
        self.callbacks.insert(id, CallbackSystem::New(Box::new(IntoSystem::into_system(callback))));
        id
    }
}

The goal is to just get this change in, and update the examples. You can simply comment out all the On::foo helpers that internally use run, which is replaced by this. If you have time left over after the examples are working, we can look at getting other things updated as well.

[musjj]

Now that bevy_mod_picking is upstreamed, will work be continued on this PR or somewhere else?

[wgxh-cli]

I have a idea! Maybe we can save those callback functions as, let's say, entities, querying and executing them when needed. This aims to decouple the bindings between so-called Event and Callback. In this case, we can even be able to cache these callbacks and related events with bevy's ecs api.

Is this accpetable?