A new function name property proposal
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.
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.
More information about the es-discuss