name property for built-in functions??

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Thu Mar 5 21:26:32 PST 2009


A number of questions/comments below

>-----Original Message-----
>From: Brendan Eich
>Sent: Thursday, March 05, 2009 5:40 PM
>Subject: Re: name property for built-in functions??
>
>On Mar 5, 2009, at 5:34 PM, Maciej Stachowiak wrote:
>
>> The authors of Objective-J and the Capuccino framework have asked us
>> to either make Function.name mutable or else provide a way to
>> construct a function with a provided name. Since they use language
>> translation, they would like the debugger and other tools to reflect
>> the original declared names such as "[MyClassName
>> methodWithParam:andStuff:]", in other words Objective-C looking
>> methods. I don't know if language translation is the world's
>> greatest thing but it seemed like a valid use case to me when they
>> suggested it.

Is the implication of the above that this name needs to be available to implementation specific debugger APIs?  If so, is providing a "name" property on function objects likely to be sufficient for supporting such APIs?

>
>In their code generation scheme, do they ever require the generated
>function to have a particular non-global scope, or will global scope do?

Are you really talking about "scopes" in the formal language sense here?  Or are you asking whether or not there is a requirement for the values of all the name property to be globally different from each other. For the latter, if the debugger API provides function identity information that is distinct from the name then I would expect that name uniqueness would not be required.

>
>If global only, then the Function constructor could make an instance
>with mutable name, maybe. Not easy to spec given that in every other
>respect the object returned by new Function is a function object, if
>we want the spec to keep name immutable for declared and expressed
>functions with names.

The spec'ing should be straight forward.  All function construction funnels through the algorithm in 13.2 which already is defined to take a "Name" argument that is currently used to specify the value used to initialize the name property.  It would be easy to extend the algorithm so that undefined means to not create the property, or to create is with a writable name property that is initialized to "anonymous" or whatever.

>
>If local or global, we could make anonymous function expressions have
>no name property at all. I'm warming up to this. We could do likewise
>for the result of Function as well. Only declared functions and named
>function expressions would have an intrinsic name property.
>

Pulling in the list from an earlier message, here is the set of cases that I believe we need to fill in with the value of the name property (if it has one) and whether or not it is writable:

   Defined by                        currently spec'ed name
FunctionDeclaration                 the identifier from the declaration
FunctionExpression with name        the identifier from the function expression
FunctionExpresion w/o name          the empty string
Object literal get/set              "get <property name>" or "set <property name>"
Bound function                      "bind <target function name>" or " bind anonymous function"
(new Function)                       "new Function"*
Built-in                            specified name

Finally, if we have such a (writable) name property is the implication that toString should be required to use it in its generated representation? 



More information about the Es-discuss mailing list