The language I used was a bit confusing with regards to the baseline and
what does what. In more direct, less spec-like language:
* Function.prototype.name is frozen and set to the empty string.
* named functions of any kind are also frozen and set to the name (how it
currently works in browsers that support name)
* class constructors maintain how they would work when desugared to a
function, so represent the class for naming
* In unnamed functions (arrow + anonymous), if there is a statically
defined name that is appropriate to use then it is set as the name, but
remains writable since the code author never explicitly set the name.
Another place where a name could be used is in assignment to member
expressions where the property name is an identifier.
The following is all the places that should be covered and result in
writable named functions:
var declFunc = function(){}
var declArrow = () => {}
var declClass = class {}
var obj = {
propFunc: function(){},
popArrow: () => {},
propClass: class {}
}
object.memberFunc = function(){}
object.memberArrow = () => {}
object.memberClass = class {}
On Fri, Nov 16, 2012 at 10:31 AM, Brendan Eich <bren...@mozilla.org> wrote:
> Brandon Benvie wrote:
>
>> This is based on http://wiki.ecmascript.org/**doku.php?id=strawman:name_*
>> *property_of_functions<http://wiki.ecmascript.org/doku.php?id=strawman:name_property_of_functions>
>>
>> Justification: the usefulness of the name of function is not just for
>> debugging. It is useful in the same ways that property names as strings are
>> such as dispatching by name or assigning by name.
>>
>> The goals expand a bit beyond the ones in the strawman, and are also
>> updated based on the current state of affairs. The first goal is that every
>> function has an own "name" property, and this property is always a string
>> (unless the user specifically decides to violate this norm), and that this
>> name property is initialized with the value that makes sense from static
>> semantics.The third goal is to allow predefined names to be altered in
>> cases where it makes sense.
>>
>
> The third goal needs more discussion. The displayName property consulted
> by certain devtools (WebKit JS profiler, IIRC; others by now) was added to
> avoid non-writable .name. With downrev browsers in the field, how can we
> make name writable and let it be used cross-browser that way?
>
>
> Semantics:
>>
>> The baseline for every function is the 'name' property defined as
>> { value: "",
>> writable: true,
>> enumerable: false,
>> configurable: false }.
>>
>
> SpiderMonkey's .name property of functions is like this except for
> writable: false.
>
>
> For FunctionDeclarations, named FunctionExpressions, MethodDefinitions,
>> or accessor Properties then the function's "name" property is set to the
>> given identifier.
>>
>
> Nit: don't define a baseline and then mutate it. Better to have the write
> immutable pd from the get-go, for each case.
>
>
> In the case of the constructor method of classes, the class name is used
>> instead. In the case of accessors, 'get ' or 'set ' is included.
>>
>
> at the front, to be super-clear ;-).
>
>
> The "name" property is set to non-writable. Function.prototype's name is
>> also non-writable.
>>
>
> Oh, I see now: you made .name writable only as a spec-internal thing. But
> wait, what about your goal 3?
>
>
> Anonymous FunctionExpressions and ArrowFunctionExpressions assigned in a
>> VariableDeclaration or ObjectExpression
>>
>
> "defined in an ObjectLiteral", rather.
>
>
> are given the name of the variable or property they are assigned to and
>> the name remains writable. Anonymous ClassExpressions follow the same
>> semantics, with the name being used for the constructor method.
>>
>
> Really great stuff here, this makes me want to back your proposal. Just
> need to hash out the nits and points of confusion (possibly mine).
>
>
> Whenever a function's name is defined by a Symbol instead of a regular
>> identifier then the name is the result of ToString(symbol).
>>
>
> Symbols don't have useful ToString conversions, do they? Are you thinking
> of the optional string passed to the constructor, for diagnostics and
> debugging?
>
>
> The name property should (probably) not have any reflection on the output
>> of Function.prototype.toString.
>>
>
> You mean if f.name is writable then f.toString() should not reflect
> updates to f.name? Agreed, but why is f.name writable?
>
> /be
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
