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
