You are correct. There is not a guarantee for the future, though I doubt this behavior will change for V8 (this is currently node only). If that scares you, you can use the combinator syntax (check out the readme towards the bottom). The object literal syntax is just sugar for using combinators.

edit: BTW, if you want some precedence in a major library relying on this behavior, look no further than Backbone's router, specifically the `_bindRoutes` method.

Sucks that it has to be so stringly typed, but I can't see another alternative.

Multimethods would be an alternative to this type of ad-hoc polymorphism. I've encoded immutable multimethod environments in my new library, bilby.js:

https://github.com/pufuwozu/bilby.js

Lets you write things like this:

    var env = λ.environment()
        .method('length', λ.isArray, function(a) {
            return a.length;
        })
        .method('length', λ.isString, function(s) {
            return s.length;
        })
        .property('empty', function(o) {
            return !this.length(o);
        });

    env.empty([]) == true;
    env.empty([1, 2, 3]) == false;

Where isArray and isString are any functions that return true/false based on the input arguments. The environment then dispatches whichever method that has a predicate return true first.

You know how a lot of jQuery functions take either a string, or a function, or an array of strings, etc? Instead of making those decisions in your code in a series of IF statements, you could use this library and just maintain a "map" of the different argument forms and have this library dispatch the right option.

In Erlang, this is used all the time to make functions that behave differently depending on how they're called - for instance, massaging a binary string into a regular string if the function only expects a regular string.

This is a small tool in a programmer's toolkit, but could be a handy one.

Pattern matching is common in functional languages like Haskell or Scala. It's like a form of overloading on steroids, letting you inspect the values and structure of the arguments passed to your function (with a very terse syntax), and do different things based on that criteria. It can also take care of a lot of boilerplate like splitting an array into different parts or extracting values from a configuration object.

Think of it as declarative nested if statements. Concise like a switch but generalized to typed values.

Take a look at the next sentence: "Keep in mind, that time is measured in the single microseconds (1µs vs 3µs) to dispatch 5 calls to the same function."

So you are still looking at sub-microsecond dispatch time for a single call. If you look at benchmark/compare.js you'll see how much shorter and clearer the pattern matched function is. I doubt this will put a strain on your performance.

edit: That said, there is likely room for optimizations and speed improvement. It will naturally take longer because it has the overhead of making function calls to the various pattern functions to check if there's a match, instead of having it all inlined like in the hand optimized function.

edit2: Sorry, this was in response to another comment that looks like it got deleted while I was editing. Now its attached itself elsewhere.

It meshes pretty well as is. If only I could get rid of the strings and redundant arguments.

  mymap = pattern {
    '_, []' : -> []
    'f, [x, xs...]' : (f, x, xs) -> 
      [f x].concat mymap(f, xs)
  }

It shares a lot of the same splat/rest/destructuring syntax.

Last I heard, jashkenas was not a fan of adding such.

"... [P]attern matching inspired by static languages is a particularly poor fit for JavaScript (and by extension CoffeeScript), because types are extremely weak in JS." -jashkenas [1]

"[... P]attern matching is not nearly as useful in a language without rich types [...]" - jashkenas [2]

I'm on that reddit thread, respectfully disagreeing with him.

[1]: https://github.com/jashkenas/coffee-script/issues/1419#issue...

[2]: http://www.reddit.com/r/programming/comments/er0qj/coffeescr...