name property for built-in functions??

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Sat Mar 7 07:44:51 PST 2009


David-Sarah Hopwood wrote:
> Brendan Eich wrote:
>> The utility of mutable name for anonymous functions is not at issue if
>> we do not define name at all on such functions -- this is the proposal
>> Allen and I were converging on. You can set name on such anonymous,
>> expressed functions to whatever value you like, delete it, shadow it via
>> .prototype/construction, etc.
> 
> I think that's a good solution; it meets the Objective-J use case without
> introducing the mutability issue raised by MarkM.
> 
>> The only issue remaining in this anonymous function case is whether
>> toString picks up the assigned name. For anonymous functions only, this
>> could be done without breaking the isolation property that allowing
>> mutation of the name initialized from the declared name of a
>> non-anonymous function would break. In fact it would seem independent:
>>
>> anonymous function referenced by variable f:
>>   * name can be set;
>>   * if set to a value converting to the string "g", then f.toString()
>> returns "function g(...) {...}" (modulo whitespace).
> 
> If name is set to a value that is not an Identifier, then the resulting
> string might not be a syntactically correct FunctionExpression or
> FunctionDeclaration.
> 
> Of course a possible response is "Don't do that".

I meant, "Don't rely on the result of toString being syntactically correct
after setting the name property to a non-Identifier."; not necessarily
"Don't set the name property to a non-Identifier."

> Since the code that
> is setting the name could do other things that would achieve the same
> effect (for example, setting 'toString'), a "Don't do that" answer may
> be adequate in this case. The function object can be sealed to prevent
> all such mutations.

-- 
David-Sarah Hopwood ⚥



More information about the Es-discuss mailing list