A new function name property proposal
brendan at mozilla.org
Fri Nov 23 09:47:43 PST 2012
Jorge Chamorro wrote:
> On 22/11/2012, at 09:38, Brendan Eich wrote:
>> Brandon Benvie wrote:
>>> I don't know the specific reasoning behind it. I guess the idea is that a function is declared in a maximum of one scope. For the declaration it's the outer scope, for a named function expression it's a static scope that sits between the outer scope and the (during execution of the function) inner scope.
>>> Also just to clarify, the above isn't something I'm proposing. It's how things currently work.
>> Right. I think Jorge may be concerned that naming a function does not always relieve the "need" for arguments.callee. But that's only true in a function declaration, which is inherently named, as you showed -- and only if one then overwrites the name in its scope.
>> So don't do that. Fear that someone else might means you are in the global scope, which means that instead of using such a hard case to justify arguments.callee, you ought to modularize with an IIFE or (in due course) ES6 module.
> To clarify, I wasn't trying to justify arguments.callee.
> "don't do that" is a solution, for this and for many other WTFs and footguns...
> But, isn't the NFEs' way the Right Way to do it?
Function declarations are useful too. They hoist so you can write them
in top-down order and call in any order from top-level code. You can't
do this with vars initialized with function expressions.
> Do we want this footgun in function declarations?
What footgun? People don't overwrite function declarations' bindings by
accident much, if at all. I can't remember hearing of this lately,
although it can happen when loading libraries where a common name is
used by two libraries.
Programmers do intentionally replace a function's name in its scope,
e.g. to auto-memoize.
> Is there any reason for not removing it? (Other than "because it's a corner case"?)
Removing what? The writable binding created by a function declaration?
That's required by backward compatibility (e.g. the memoization pattern).
More information about the es-discuss