A new function name property proposal

Aron Homberg info at aron-homberg.de
Fri Nov 16 11:34:06 PST 2012

I implemented a JS parser last week (in JS) which specially parses the
function grammar. It also analyzes the function names based on the rules
you described, Brandon. I came to the same results when thinking about how
function names could be detected (statically).

But... there are some special cases where I wasn't able to find a good way
to detect a function's name properly. In one case, thats because my parser
just does a simple static parsing. Due to this, symbols are not evaluated
by toString(), like mentioned. But that's not the end of the story, there
are more pitfalls in practice...

A) Anonymous FunctionExpression's, stored in an array:

var someArray = [function() {
    // Have
}, function() {
    // a
}, function() {
    // lot of
}, function() {
    // fun

e.g. Sencha's Ext JS does this in their Ext.data.Connection class where
it's used to determine which ActiveXObject instance to choose for an
XMLHttpRequest impl. in IE (calls the function in a loop)

I thought about combine sombol-name with array index, to give them a name.
It would look like: "someArray-0", "someArray-1", etc. but somehow I don't
really like that. Currently they are 'called': "anonymous-" + sequence++ -
I increase this sequence with each anonymous function detected to give
these functions a unique name (in script context).

B) FunctionExpression's assigned to a symbol:

var foo = {
    barFn: null

foo[barFn] = function() {
    // whatever

I faced this kind of code when parsing jQuery 1.8.1. It's hard to find a
smart way here. The property name could be a function call too or whatever.
So the name of the function is detected as "symbol-assigned-anonymous-" +
sequence++ here. For sure, function name could be "foo[barFn]" too. Maybe,
thats better for a developer in practice. With static analysis, these both
solutions are all I can do here. But dynamic evaluation of the symbol and
casting to a String, is too much for my static parsing algorithm.

Imagine stranger situations:

foo[fetchPropertyName()] = [function() {
    // no
}, function() {
    // fun

Here a static function name detection fails too. A dynamic symbol to String
conversion can be dangerous in such a situation too, right?

C) Scoped functions:

(function() {
    // what's my name?

No chance, this one is totally anonymous, right? No matter if static or
dynamic code analysis/parsing.


Now in practice: (parsing jQuery 1.8.1)

When I parse jQuery 1.8.1 using my parser, 511 functions get parsed and
their names get detected correctly. 137 functions apply to one of the three
special cases above. Most of them are symbol-assigned. Few are scoped by
(). One additional function is being instantiated using "new
Function('$code')". I didn't implemented a name detection for this grammar
yet, so 138 of 511 functions are somehow "anonymous" after detecting
function names using my static parsing algorithm.

I wonder what your thoughts are regarding these special cases and my
decision to fallback to "symbol-assigned-anonymous-" + sequence++. Would
you prefer using the sourcecode of the symbol assignment as detected
function name name? It would be more descriptive in practice, right?

@Alex: "The name would be more useful if it could be either string or
Please help me out :) The function will be assigned to the symbol, right?
So using the symbol as name would simply be a reference to the function
itself and equals to arguments.callee? Or did you mean the sourcecode of
the symbol as the detected name of the function like I mentioned above?

Thanks and regards,
- Aron

2012/11/16 Axel Rauschmayer <axel at rauschma.de>

> Whenever a function's name is defined by a Symbol instead of a regular
> identifier then the name is the result of ToString(symbol).
> Symbols don't have useful ToString conversions, do they? Are you thinking
> of the optional string passed to the constructor, for diagnostics and
> debugging?
> The name would be more useful if it could be either string or symbol. Not
> sure about security implications, though.
> --
> Dr. Axel Rauschmayer
> axel at rauschma.de
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121116/ce73e6ce/attachment-0001.html>

More information about the es-discuss mailing list