The solution: Instead of defining single functions for callbacks, maintain a list of them and then build a chain of continuations. Here is the completed code for managing our callbacks: http://gist.github.com/136525. This expands on Jason’s continuations: http://lonelypinkelephants.com/continuing.html.

The old way was to do something like this:

// file 1
Controllers.Hydra = {
  on_load : function() {
    do_whatever_is_defined_by_default()
  }
}

// file 2
Controllers.Hydra = {
  on_load : function() {
    do_something()
    do_this_other_thing()
    do_whatever_is_defined_by_default()
  }
}

And then in the code that actually cares:

onload="Controllers.Hydra.on_load()"

This means the overloading method must know about what the default behavior is and it can only be overloaded once.

The new (awesome) way:

// file 1
Callbacks.add(Callbacks.Hydra.on_load, do_whatever_is_defined_by_default)

And:

// file 2
Callbacks.add(Callbacks.Hydra.on_load, do_something)
Callbacks.add(Callbacks.Hydra.on_load, do_this_other_thing)

And in the code that actually fires the callback:

onload="Callbacks.start(Callbacks.Hydra.on_load)"

The callbacks are called in order.

What else can we do with this? One of the features I like about Rails is that if a callback or filter returns false the rest of the chain is halted. We’ve included that behavior too (This doesn’t necessarily affect what ever called start on the callback chain).