-
Notifications
You must be signed in to change notification settings - Fork 6
Add the Event class for fine-grain control of event dispatch #15
Conversation
Maybe I misunderstand something here but I see two different concepts in the same class:
Otherwise it is an interesting enhancement. |
Yep, I was hoping to kill two birds with one stone. The goal is to encourage users to move as much code out of interrupt context as possible. Unfortunately, default behaviour is interrupt context, which makes it easy to suddenly find yourself in an interrupt. But we can encourage better behaviour through syntactic sugar. Currently (with this patch), this is the easiest method to move events out of interrupt context: Event<> event(queue, func);
ticker.attach(&event, &Event<>::call, 10); However, this forces the use of method pointers, which can be intimidating to new users. With the Event<> event(queue, func);
ticker.attach(event, 10); If we want to avoid this syntax for now, I can split the function-like operations out into a different pr, which can stagnate until such overloads are added to mbed-os. If we go this route, it would be beneficial to add a Event<> event(queue, func);
ticker.attach(&event, &Event<>::post_void, 10); |
What about: operator Callback<void(A0,...)>() {
return Callback<void(A0,...)>(this, &Event<A0,...>::post_void);
} It would still be possible to write: Event<> event(queue, func);
ticker.attach(event, 10); but not: Event<> event(queue, func);
event(); What do you think ? |
Hmm, that is a good idea. My only concern is a running concern I've had with the clarity of ownership. It would be very easy for even an experienced user to take your example and expect the following to work: EventQueue queue;
void setup() {
Event<> event(&queue, func);
ticker.attach(event, 10);
}
int main() {
setup();
queue.dispatch();
} Looking into related concepts, it looks like the As an alternative, what are you thoughts on instead adding a private EventQueue queue;
void setup() {
Event<> event(&queue, func);
ticker.attach(&event, 10);
}
int main() {
setup();
queue.dispatch();
} |
100% agreed overloading |
@pan-, I've removed the Any concerns with the updated pr? |
4da36ae
to
5f937f1
Compare
For a more fine-grain control of event dispatch, the Event class can be manually instantiated and configured. More information and examples can be found in the updated readme and documentation in Event.h
Before: Event<> e = Event<>(&queue, func); After: Event<> e = queue.event(func); Unfortunately, this technique only works for full bindings since the event class does not recognize the actual parameter types for functions. As such, the queue.event function can only return "Event<>".
Before: Event<A, B, C> After: Event<void(A, B, C)>
For a more fine-grain control of event dispatch, the Event class can be manually instantiated and configured. An
Event
represents an event as a C++ style function object and can be directly passedto other APIs that expect a callback.
From the updated readme:
cc @pan- thoughts?