"Pretty" function expression names

[Lasse R.H. Nielsen]

On Mon, 04 May 2009 19:45:19 +0200, P T Withington <ptw at pobox.com> wrote:

> Assuming we're allowed to speculate on futures here...
>
> I was thinking about improving debug-ability by adding descriptive
> names to function expressions thusly,
>
>    var myFun = function "my description here" (...) { ... };
>
> I.e., be able to use an arbitrary string as the "name" of a function
> expression.  It seems to me this would be an unambiguous extension,
> only giving up an unlikely syntax error.  No runtime is required to do
> anything with the name, although it would be encouraged to make it
> available as the .name property of the function object.  Comments?

I think this is an attempt at combining two features into one (syntactic) field.
The function name (the identifier after "function") allows you to bind a name to the function for recursive use.
The string suggested here allows you to add a *description*, not a name.

While a description is nice for debugging, it's not the same as a name,
not even a descriptive name.

If a description is wanted, I would prefer something similar to the the elisp way of doing it.
If the first statement of the function body is a string literal, it is the description.

I.e., 
  function foo(bar, baz) {
    "Way to foo the bar and baz";
    // body
  }

This has the advantage of allowing descriptions and names on the same functions,
and it is just as easily represented in the function's toString representation.
Even internal functions can use it:

  String.prototype.toString.toString() ->  
     'function toString() {
          "String.prototype.toString";
          [ native code ]
      }'

You might then access it as functionRef.description (or something similar).


On the other hand, this is also just using one syntactic feature (string literal) for another purpose: a special type of comment. 


It will allow a debugger to show different names for similarly named functions, e.g. {Object, String, Number, Boolean, Date, RegExp}.prototype.toString, which
all have the exact same display now:
 function toString() {
     [native code]
 }
(from Firefox).

On the other hand, nothing prevents an implementation from doing that already (it's already valid syntax, and only a small change of toString is needed to print it out). It's only a standardized accessor for the description that is missing.

/L
-- 
Lasse R.H. Nielsen
'Faith without judgement merely degrades the spirit divine'