A new function name property proposal

Jorge Chamorro jorge at jorgechamorro.com
Wed Nov 21 01:02:06 PST 2012


On 19/11/2012, at 20:34, Brandon Benvie wrote:
> 
> On Mon, Nov 19, 2012 at 2:29 PM, Jorge Chamorro Bieling <jorge at jorgechamorro.com> wrote:
>> On 17/11/2012, at 18:45, Brandon Benvie wrote:
>> 
>>> The name property doesn't currently (and the I don't propose it should) have a correlation to the name in scope. In function declarations the name is only in scope because its declared in the outer scope, and this can be overwritten permanently rendering the name unusable in that scope. A named function expression
>> 
>> --and function declarations too--
>> 
>>> puts the name association in a decorative scope that is untouchable and only accessible inside the function.
>> 
>> It's not clear to me whether one might end with function whose name (the value returned by function.name) might be !== than its name as "seen" from inside the function itself:
>> 
>> function ƒ () { return (ƒ.name !== 'ƒ') }
>> 
>> ?
> 
> function x(){ x = { name: 'y' }; return x.name } x(); // 'y'
> 
> (function x(){ x = { name: 'y' }; return x.name })() // 'x'

The behaviour of the function declaration surprises me for since the days of the discussions about the ditching of arguments.callee, I seem to recall, one of the arguments in favor of ditching it was that a reference to itself was already available there, inside the named function, safe and in scope, *ever*, and not only in the case of (named) function expressions.

Having it declared (only) in the outer scope has risks that arguments.callee didn't have, and that NFEs don't have. Is there any justification for this difference?
-- 
Jorge.


More information about the es-discuss mailing list