Feature: Event Manager

[HiImJulien]

First of all: Sorry if this issue is kind of odd or just totally wrong here. I am new to GitHub and with this issue I'd like to suggest a feature for Anax. I'd like to implement this feature in a fork of mine.

The feature I would like to suggest is some sort of a event managment mechanism to achieve the following goals:

• Notify me about arbitrary events, (I subscribed to).
• Notify systems about events, they subscribed to.

The way one interacts with the event-manager could look like this:

EventManager mgr;

struct Event{};

void foo(Event* event){
    DoSomethingAwesome(event);
    DoSomethingEvenMoreAwesome(event);
}

class EventHandler{
    public:
         void handle(Event* event){
             // You guess it
            EvenMoreAwesomeDoSomething(event);
         }
};

int main(){

    // Subscribe to the event
   mgr.bind<Event, foo>();
   EventHandler handler;
   mgr.bind<Event, EventHandler, &EventHandler::handle>(&handler);

   // Emit (Trigger) the event
   Event event;
   mgr.emit(&event);

    return 0;
}

Internally the implementation would rely on a std::map<uint32_t, std::vector<Callbacks>> sort of container, whereas each event has an unique id.

However, even though this was just a quick draft of how I imagine the actuall implementation I'd love to hear your opinions.

With kind regards

Julian

P.S.: Sorry if some expressions are unclear or even spelled wrong, I corrected all mistakes I found, yet englisch ain't my mother tongue.

[miguelmartin75]

I'm not convinced that it belongs in this library, I don't see why you wouldn't just use a signal/slot library or another library (e.g. just basic abstract [virtual] interfaces).

I've basically implemented this in another library of mine. Though, it is not thread safe (subscribing and pushing out events; and anax is not thread safe either lol). Another library you could consider using (and what I would recommend) is boost.signals2 as it is thread safe and a very nice library which is what I based my library off of (in terms of design).

[HiImJulien]

The idea is loosely based on the signal-slot-mechanism, even though I don't use Don Clugston's "FastDelegate", since I prefer my own solution which is compilant with the standard and is evaluated completely at compile time.

The main motivation behind this feature-request is, that the signal'n'slot mechanism needs to know about the class itself, which triggers the event, and needs to manage its lifetime (e.g. for unsubscription).

Instead I'd decouple the signals from the slot by introducing a global (not quite sure about it; one per world) class, that manages the coupling on its own.

P.S.: Nice work on 'Wink' ;)