Existing Dispatch Methods

Dispatch is the process of mapping a function call to a specific function based on its arguments. Most of the time this is done at runtime through the binding phase, however it usually lacks of modularity.

Dispatch by Type

The first way dispatch has been implemented is through function overloading. Two functions share the same name and depending on the type of the argument, a choice will be made to call the right one.

int   sqr(int i)   { return i * i; } // int version
float sqr(float i) { return i * i; } // float version

When entering the Oriented Object world, there is a more powerful way to dispatch that is not only based on the type but also the type hierarchy. You can allow an object of type A to use the method implementation of one of its children.

class A { public: virtual void print() = 0; };
class B : public A { public: void print() { std::cout < < "B" << std::endl; }; };
class C : public A { public: void print() { std::cout < < "C" << std::endl; }; };
void doPrint(A& a) {
  // A doesn't have a definition of the print method
  // There is an implicit dispatching to determine which of the B::print or C::print 
  // will be called. This is done at runtime

This is a single dispatch since we could see the print function this way: void print(B this) { ... }. In C++ we are limited to only one dispatch, even if Stroustrup proposed a way to support multimethods in C++. The main problem is that it's being limited to types.

Dispatch by Constant Value

There are ways to use other criteria in order to dispatch, for example the use of numerical constants. In C++ the way to do it is to use templates.

// General case
template < int N >
struct fact {
  enum { value = N * fact< N - 1 >::value };
// Specialization for n = 0
template <>
struct fact< 0 > {
  enum { value = 1 };

You have a code that will run differently depending on the parameter. We can now write functions that work for specialized types and that takes in account their type hierarchy and for specialized cases represented with numerical constants.

If you want to do fancier things, you are stuck! Your only way to achieve the result you expect is to write custom branching yourself. This is where Full dispatch comes in action.

Full Dispatch

Full Dispatch instead of redirecting to the right function based on hard-coded parameters such as the type or the equality of the argument with some constant, allows you to provide a function for each argument.

This way, you will be able to dispatch the function based on the criterion you want. You are no more stuck with a special subset of the language.

You would like to write something like this:

int fact(int n : n == 0 || n == 1) { return 1; }
int fact(int n) { return n * fact(n - 1); }


To dispatch, we have to know two informations for each overriding method: the actual function and a list of boolean function to test against the parameters.

I've chosen to store it as an array of overriding method, where the overriding is stored as an array containing in first element the actual function followed by the argument conditions.

The dispatching function is trivial to write, you just have to walk through that table and if all the arguments match the conditions then call it.

function fullDispatch(arg, list) {
  outer: for (var i = 0; i < list.length; ++i) {
    if (list[i].length - 1 !== arg.length) {
      // Arguments length is different than number of conditions, no need to continue
    for (var j = 0; j < arg.length; ++j) {
      if (typeof list[i][j + 1] === 'function' && !list[i][j + 1](arg[j])) {
        // Condition fail, try next overriding function
        continue outer;
    // Execute the right function
    return list[i][0].apply(this, arg);
  output.error('no dispatch found');

And here is the code to use it for the factorial function:

var fact = function () {
  return fullDispatch(arguments, fact.list);
fact.list = [
  [function (n) { return 1; },
    function (n) { return n === 0 || n === 1; }],
  [function (n) { return n * fact(n - 1); },

Helper functions

Most of the time, the condition functions will be trivial to write and will make the code unreadable because of the verbose way to declare an anonymous function.

The first step to make this cleaner was to allow null to be used when you don't want to impose any condition on the argument. It means "always return yes" and avoid a useless function call.

Then, we want to avoid to write basic conditions such as "is zero" or "is negative". Using the power of lambda function in association with closure, it's possible to write generics helpers to make these with no effort.

var helper = {};
// Combination
helper.or = function (f, g) { return function (x) { return f(x) || g(x); }; };
helper.and = function (f, g) { return function (x) { return f(x) && g(x); }; };
helper.not = function (f) { return function (x) { return !f(x); }; };
// Primitives
helper.Value = function (n) { return function (x) { return x === n; }; };
helper.StrictNegative = function (x) { return x < 0; };
// Primitive Combinations
helper.Zero = helper.Value(0);
helper.Negative = helper.or(helper.StrictNegative, helper.Zero);
helper.StrictPositive = helper.not(helper.or(helper.Zero, helper.StrictNegative));
helper.Positive = helper.not(helper.StrictNegative);

Of course, the shown primitive combinations could be written directly but this shows you how to construct and use complex functions based on few bricks.

Final Result

This is an example of the ackermann function written with the Full Dispatch method and the little helper functions.

var ackermann = function () {
  return fullDispatch(arguments, ackermann.list);
ackermann.list = [
  [function (m, n) { return n + 1; },
  [function (m, n) { return ackermann(m - 1, 1); },
  [function (m, n) { return ackermann(m - 1, ackermann(m, n - 1)); },

Write Less, Do More

The current version works well but is the syntax is too heavy. In order to make this work we have to copy each time the fullDispatch call which isn't good. We can use a function generator to do the work.

We want to put the conditions first, since they will tend to be smaller, they will appear nicely in one line just before the function definition. And having a setter could be interesting, this would allow to check the input and hide the structure from the user.

Applying these modifications, we would have a code that look like this:

var ack = FullDispatch();
ack.add([Zero, null], function (m, n) { return n + 1; });
ack.add([StrictPositive, Zero], function (m, n) { return ack(m - 1, 1); });
ack.add([StrictPositive, StrictPositive], function (m, n) { return ack(m - 1, ack(m, n - 1)); });
ack.add([null, null], function (m, n) { return 0; });

Which is a pretty nice result. This is not as short as the haskell code but this doesn't use any syntaxic sugar from the language and can be used with any kind of argument conditions.

ackermann 0 n = n+1 
ackermann (m+1) 0 = ackermann m 1
ackermann (m+1) (n+1) = ackermann m (ackermann (m+1) n)
ackermann _ _ = 0

To make this work we create a function that is going to to the real dispatch and augment it with the setter and the function list.

var FullDispatch = function () {
  // Create the function that does the real dispatch
  var object = function () {
    return fullDispatch(arguments, object.list);
  // Give the setter to the function
  object.add = function (conds, func) {
  // Initialize the function list
  object.list = [];
  return object;


The code demonstrated here can been seen working in a demo.


This little library is working well as it is. There is still some work to do in this field. First, we have to find uses for this pattern. I haven't thought yet of any uses of it and the example provided do not show the real benefit of such a tool. I am pretty sure now this is known and implemented some of you will find how to use it!

The second point is performance issues. Having such a modular dispatch system is great for expressiveness but come at a price. The overhead is pretty huge. One dispatch of a call costs at most n * m where n is the number of overriding functions and m is the number of arguments.

Functions can be added a way that only one (or two) conditions are tested each time. By mimicking the way you would write a branching using if-then-else, the overhead is one function call per condition (and per argument).

It's certainly enough to avoid when performance is required, however I am confident this is acceptable in most conditions compared to the flexibility it gives. Benchmarks would be more than welcome.

If you liked this article, you might be interested in my Twitter feed as well.
  • bebraw


    I found a great way to use full dispatch in my work. I'm currently developing an utility library. I started using fuzzing early on to test some of my functions. The problem with this approach was that in order to fuzz a function I had to define generators explicitly. This didn't feel right and the syntax was a bit cumbersome.

    A while ago I decided to try something different. What if I annotated function parameter invariants near function definition? This took me near DbC or rather precondition part of that. I don't provide support for postconditions yet though it might be an interesting thing to add and quite easy even.

    This line of thought lead into the creation of annotate.js. In addition to handling with dispatch, it attaches certain metadata to my functions. I am able to leverage this metadata later on in various ways.

    One of those ways is fuzzing. Now that I have information about invariants, I can simply generate values that pass those and then execute these values against my tests (another kind of invariants, they usually contain some mathematical truth). I have instrumented my testing library, suite.js, to do just this.

    I can leverage the metadata in other ways too. I intend to generate the documentation for my utility library using it. I find this quite elegant solution compared to other libraries out there. They seem to maintain their documentation and examples more or less by hand. I won't have this problem.

    I hope this not so brief reply gave you some idea how to leverage the pattern. It seems quite powerful when combined with fuzzing and other techniques.


Related Posts

  • August 20, 2011 Idea – mouseFreeze – A solution for Browser FPS Games (8)
    There is an open problem in porting real game into the web browser related to cursor handling. Problem Many games such as First-Person Shooters require the mouse to freely move, without the constraints of screen edges. However there is no such API in the browser to make this […]
  • October 28, 2011 JSPP – Morph C++ Into Javascript (Paper) (0)
    6 months ago, I wrote the blog post "JSPP - Morph C++ into Javascript". My supervisor at the LRDE (R&D Lab of EPITA), Didier Verna, found it interesting and told me that it could be worth a publication. With his great help, I've written my first article. We have submitted it to two […]
  • January 11, 2012 Javascript Ray Tracer (1)
    Here is a report of the Ray Tracer written by myself Christopher Chedeau. I've taken the file format and most of the examples from the Ray Tracer of our friends Maxime Mouial and Clément Bœsch. The source is available on Github. It is powered by Open Source technologies: glMatrix, […]
  • September 17, 2011 WoW Interface Anchor Positioning (5)
    I've always found CSS positioning with both float and position: absolute/relative hard to work with. I want to introduce to you an alternative way borrowed from the World of Warcraft Interface: Anchors. Anchor The concept is extremely simple. You can tell where you want the element […]
  • August 23, 2011 Javascript – Hook Technique (5)
    Let's go back 5 years ago during the World of Warcraft beta. I was working on Cosmos UI, a projects that aimed to improve the World of Warcraft interface. As interface modification was not officially supported by Blizzard, we went ahead and directly modify the game files written in […]