name functions via the displayName property

[pmuellr]

There is a convention used by at least the following debuggers to allow anonymous functions to be named by the source code:

• Web Inspector
• FireBug
• weinre

The convention is that a function which otherwise doesn't have a name property which is a string, will be checked to see if it has a displayName property, and that will be used in lieu of the name. The convention was originally added to Web Inspector by the Objective-J developers.

I would like this support added to CoffeeScript as a new option of the coffee compiler.

There's less need for this today, with the JS engines doing name inferencing for anonymous functions, but not all JS engines support this. In addition, the JS engines that weinre supports (eg, on mobile devices) are typically older than their desktop brethren, and are less likely to have that support.

Even with name inferencing, some folks might prefer a slightly cleaner look.

Proposal:

• new command line option -f which will add the displayName property to every function CoffeeScript produces, except for constructors which are already named.
• I see 4 forms of functions, which would presumably have different naming styles:
  • static methods of a class: (className)::(methodName)
  • instance methods of a class: (className).(methodName)
  • functions in a class: (className):(functionName)
  • functions not in a class: (functionName)

I'm not married to the choice separators in the names, that was just my initial thought.

Methods in a class should be babycakes; functions will be harder, and I don't have a sense for how much harder. Certainly, there are cases where there is no obvious name, and those functions should be left anonymous.

Here's an example.

CoffeeScript:

class X
  @a: () -> a
  b: () -> b
  c = () -> c

d = () -> d

JavaScript produced today:

var X, d;
X = (function() {
  var c;
  function X() {}
  X.a = function() {
    return a;
  };
  X.prototype.b = function() {
    return b;
  };
  c = function() {
    return c;
  };
  return X;
})();
d = function() {
  return d;
};

JavaScript produced tomorrow with the -f option:

var X, d;
X = (function() {
  var c;
  function X() {}
  X.a = function() {
    return a;
  }; X.a.displayName = "X::a"
  X.prototype.b = function() {
    return b;
  }; X.prototype.b.displayName = "X.b"
  c = function() {
    return c;
  }; c.displayName = "X:c"
  return X;
})();
d = function() {
  return d;
}; d.displayName = "d"

[pmuellr]

I'd be happy to work a patch for this, but wanted to see if there was a hope that a contribution for this new function would be accepted, before starting the work.

[jashkenas]

You hit the nail on the head as to why this isn't desirable ...

There's less need for this today, with the JS engines doing name inferencing
for anonymous functions [...]

The displayName property was a temporary hack, needed because name inferencing wasn't available at the time. In general, inferenced (dynamically bound) names are far superior to static names defined at the same time the function is. For example:

f(x){ return this.total + x; }

ShoppingBag.prototype.add = f;

Counter.prototype.increment = f;

... it's totally fantastic that when debugging, you'll see the two proper different names for the function, instead of f.

Feel free to add displayName in your fork -- it should be fairly easy to add -- but it shouldn't be available on the main line.