substitutes for arguments and arguments.callee in ECMAScript 5
Allen Wirfs-Brock
allen at wirfs-brock.com
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.
Allen
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 wirfs-brock.com> 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 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/20110105/ced1d0f2/attachment.html>
More information about the es-discuss
mailing list