name property for built-in functions??

Brendan Eich brendan at mozilla.com
Wed Mar 4 13:17:21 PST 2009


On Mar 4, 2009, at 9:49 AM, Allen Wirfs-Brock wrote:

> I’m not sure that there ever was a stated requirement that  
> Function.prototype.name 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.

Historical note: name in SpiderMonkey and the Netscape progenitor  
predate ES3 and RegExps (RegExps based on Perl 4 were coming along  
before ES3 standardized Perl-5-ish RegExps).

Fairly simple regexps can do a great many things, as David-Sarah  
pointed out re: parseInt weakness. That's no reason for varying name  
from its obvious connotation if the primary use-case is getting the  
same name that follows 'function' in the toString result.


>    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.

It's a roll of the dice; I recall saying we would have to implement  
and see how it went.

Use-case analysis needs user testing. If you think the use-case is a  
diagnostic informative identifying string to be formatted into a  
localized sentence, multiple words separate by spaces are problematic  
for l10n and ambiguity reasons.

It seems to me we should not be making stuff up here that has not  
already been implemented. If we must, we could try to get feedback  
from prototype 3.1 implementations. We can't afford to do too much of  
this late innovation, though, because we won't be able to get  
sufficient user testing for very much novelty, in the time alloted.


> If we really want to establish a Function.prototype.name/ 
> Function.prototype.toString invariant then we need to also worry  
> about what happens if Function.prototype.name 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?

Why in the world is name writable?

js> function f(){}
js> f.name
f
js> f.name = 'g'
g
js> f.name
f

It's not in Mozilla's implementations. AFAIK there's no precedent  
elsewhere that has name predefined yet writable.


> 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?

I'm fine with dropping the Function name property from 3.1. We should  
develop a Harmony proposal that can be prototyped and tested at  
greater leisure if we drop it, not just drop it and ignore the  
progress made so far on this point.


> 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.

It would be bad to overspecify, e.g. whitespace or comment  
preservation, or particular formatting. Existing code copes with  
various implementation artifacts. What is not good is the failure to  
produce anything compilable for a scripted function, or something that  
miscompiles to a function not isomorphic to the original.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090304/c2b58a5d/attachment.html>


More information about the Es-discuss mailing list