name property for built-in functions??

Allen Wirfs-Brock Allen.Wirfs-Brock at
Wed Mar 4 09:49:00 PST 2009

I'm not sure that there ever was a stated requirement that yield the same value that appears in  the identifier position of a Function declaration/expression text produced by toString.  If that was to be the case,  then name offers very little added value as the identifier can be extracted from  from  the toString value with a fairly simple RegExp.   It always seemed to me that the real utility of the proposed name property was to provide additional  descriptive information about functions that might be useful for debugger.  The underscored prefix does provide this except for the obvious ambiguities with functions explicitly named in that manner. We did discuss this at the MV meeting in the context of name bind functions and object literal get/set functions and nobody seems concerned about the space in those names.

If we really want to establish a invariant then we need to also worry about what happens if is modified (it's [[Writable]]:true) and in particular if its value is set to a non-string.  Do you want toString to specify that it just uses ToString() applied to the value of the name property?

Last fall, we dropped Function.prototype.arguments because of unresolved issues that were no more complex then these.  Are we getting to the same point here?

Finally, I think the really important issue from an interoperability perspective is the toString issues that Maciej pointed out.  Regardless of what we do with the name property I think we need to better specify it for consistent interoperability and compatibility with the existing web.  I think the proposal for toString in my  earlier message addresses those concerns.


From: Mark S. Miller [mailto:erights at]
Sent: Tuesday, March 03, 2009 8:02 PM
To: Allen Wirfs-Brock
Cc: Brendan Eich; Maciej Stachowiak; es-discuss at
Subject: Re: name property for built-in functions??

I like most of what you just proposed, except that I find it surprising that a function's ".name" is not the identifier used by ".toString()" on that function. This same issue just came up on an internal list at Google: Objecting that since ES3.1 specs that the ".name" for bound functions and literal getters and setters is not an identifier, it would break .toString() if it were used in the identifier position of a function's .toString().

On Tue, Mar 3, 2009 at 7:35 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at<mailto:Allen.Wirfs-Brock at>> wrote:
A quick post-script.  We could also give<> a different name, perhaps "identifier" if we don't want to trample over the existing FF and Chrome implementations.  Too bad "name" is such a good name for this functionality.

The other way to reconcile this is to retreat to keeping the name "name", but having it always agree with the identifier used the function's .toString(). If we do this, then we should choose a good enough identifier mangling scheme for bound functions ("bind_<original-ident>") and literal getters and setters ("get_<ident>", "set_<ident>"), and use it in both the .name and in the identifier position of .toString(). Ugly as this is, I think it's better than having two different names associated with the same function by two different parts of our API merely because we couldn't agree on one.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list