A new function name property proposal

Brandon Benvie brandon at brandonbenvie.com
Fri Nov 16 12:46:42 PST 2012


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
<johnjbarton at 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 <info at 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 <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
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> 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/81cae78c/attachment.html>


More information about the es-discuss mailing list