

The Callback Hell - rumcajz
http://www.250bpm.com/blog:24

======
ambrop7
I've posted some comments there explaining a design pattern I've found that
pretty much solves the "callback hell".
<http://www.250bpm.com/blog:24/comments/show#post-1784877>

The basic idea is to integrate a LIFO event queue into the event loop, whose
events take priority over other events (fds, timers). Then whenever you want
to write code something like that:

    
    
      func() {
        call_callback();
        do_something();
      }
    

Instead you do:

    
    
      func() {
        push after_callback_event;
        return call_callback();
      }
    
      after_callback_event() {
        do_something();
      }
    

The LIFO nature of the event queue guarantees the expected event processing
order, that is, the after_callback_event() is invoked after call_callback(),
including any events call_callback() itself pushes, recursively.

The other thing that helps a lot is to reduce coupling in your code. With
reduced coupling, the "what can be called back when I call this" problem
becomes much simpler. Components can't call other components that they don't
know about.

I can say that by applying the LIFO and taking care to decouple my components
properly, my event driven code is certainly not suffering from the "callback
hell". Quite the opposite, I think it is nice and correct :) I'm talking about
the programs in my open source project here,
<https://code.google.com/p/badvpn/> .

