Yeah, once you try to get fancy with interpolating a name you go down a dark path real quick. I think that tends to be more in line with the concept behind displayName which is the debug flavor of this and wants to do heroic feats to trace a usable debug name. The name property should be something that you'd actually purposefully write out yourself, not a derived object path. This is where the writability comes in. If the author does fail to hit the mark and doesn't provide a usable name, they can at least manually set it after the fact.
On Fri, Nov 16, 2012 at 2:43 PM, John J Barton <johnjbar...@johnjbarton.com>wrote: > You might be interested in the work of Salman Mirghasemi on anonymous > function naming in JavaScript: > http://johnjbarton.github.com/nonymous/index.html > > jjb > > > On Fri, Nov 16, 2012 at 11:34 AM, Aron Homberg <i...@aron-homberg.de>wrote: > >> 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 >> symbol" >> 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 <a...@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 >>> a...@rauschma.de >>> >>> home: rauschma.de >>> twitter: twitter.com/rauschma >>> blog: 2ality.com >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
