From: Brendan Eich [mailto:[email protected]]<mailto:[mailto:[email protected]]> > Why in the world is name writable?
Default ES3.1 policy for new properties that are added to the spec. is to make them writable in case there is existing code that coincidentally uses that property name for other purposes. If this isn't a concern for Function.prototype.name (and Mozilla's use of it suggests that this is probably safe) then it could be specified as non-writable. > I'm fine with dropping the Function name property from 3.1 I think that might be best, although we would still need to define the toString name for all possible function creation scenarios. > It would be bad to overspecify, Agreed. It's only the name that I think we need to further specify toString. I'm fine with the current formatting variations. From: Brendan Eich [mailto:[email protected]] Sent: Wednesday, March 04, 2009 1:17 PM To: Allen Wirfs-Brock Cc: Mark S. Miller; Maciej Stachowiak; [email protected] Subject: Re: name property for built-in functions?? 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
_______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
