substitutes for arguments and arguments.callee in ECMAScript 5

Allen Wirfs-Brock allen at
Wed Jan 5 13:29:44 PST 2011

Yes, there is more too it, as Kangax and MarkM point out. But I think we are at the point where we are just adding noise to this conversation.  Felipe was just asking for an alternative to arguments.callee for referring to the value of a function expression from within the body of the function.  A named function expression with a well chosen name is a very interoperable way to easily do this.  All the other semantic subtleties and implementation variations in the handling of block nested declarations are not really all that relevant to straight-forward usage of that pattern.


On Jan 5, 2011, at 1:03 PM, Juriy Zaytsev wrote:

> On Wed, Jan 5, 2011 at 3:48 PM, Allen Wirfs-Brock <allen at> wrote:
> Just a couple additional points to make sure that Brendan and I playing tag-team aren't sowing further confusion about this topic:
>  ...subscribe(function func() {...})
> according to the ES standard is a different construct from either
>>> var foo = function() { ... }
> or
>>> function foo() { ... }
> In particularly, the latter two introduce a declaration for the name "func" into the surrounding scope so it can be referenced anywhere in that scope.  The first function expression form introduces a declaration for "func" that is supposed to only be visible from within the {...} function body. Also, the function expression form has a well-defined meaning anywhere including in the compound statement blocks such as if-statements.  The meaning of the latter two declaration forms are not defined by the standard when they occur within compound statement blocks.  What they do, depends upon the browser.
> IE, prior to IE9, didn't conform to the standard for function expressions and makes the name "func" visible in the surrounding scope.  
> There's a little more to it. 
> IE<9 actually creates 2 function objects when parsing NFE; not just leaks identifier to the enclosing scope. It might seem irrelevant at first, but if you consider that something like `var f = function g(){ ... } ` will result in creation of 2 distinct function objects bound to `f` and `g`, it's easy to imagine how this could lead to all kinds of lovely bugs (e.g. when assigning to a property of function object; and having that property on `f` but not `g`, or vice versa).
> [...]
> -- 
> kangax
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list