A new function name property proposal

Brendan Eich brendan at mozilla.org
Fri Nov 23 22:14:33 PST 2012


Jorge Chamorro wrote:
> On 23/11/2012, at 18:47, Brendan Eich wrote:
>> Jorge Chamorro wrote:
>>> On 22/11/2012, at 09:38, Brendan Eich wrote:
>>>> 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?
>> Do what?
>
> Bind the name inside the function *too*.

That's not a compatible change, and unmotivated by any actual foot damage.

>>> Do we want this footgun in function declarations?
>> What footgun?
>
> The footgun (1) is to have the name bound *only* in the outer scope.

We need evidence this is a real hazard. Otherwise you're assuming a 
conclusion and using a circular argument of sorts: that lack of the 
inner unwritable name binding is a problem requiring just that solution.


>> 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.
>
> Yes it's a corner case.

Ok, so what's the non-corner foot-damaging case?

>> Programmers do intentionally replace a function's name in its scope, e.g. to auto-memoize.
>
> Oh, how does that work? I've written memoizers but never needed to overwrite a name.

http://osteele.com/posts/2006/04/one-line-javascript-memoization

Works on global functions as well prototype methods.

>> The writable binding created by a function declaration? That's required by backward compatibility (e.g. the memoization pattern).
>
> The -outer- writable binding isn't the problem, the problem is the lack of binding in the inner scope. Is there a reason for not having it?

Again, introducing such a binding is an incompatible change. I don't 
know what it might break, but I doubt anyone wants the risk. Also 
there's overhead in making such an inner binding -- another reason 
implementors won't go there. Finally, you have not justified this change 
by any evidence it addresses a real, observed hazard.

/be


More information about the es-discuss mailing list