In regards to Symbols, yeah I was taking for granted them having a usable
value coming ToString that originates from the argument to the constructor.
I imagine that with syntactic support for Symbols this can mostly be
automated by lifting the ToString representation from the Symbol's
declaration.
On Fri, Nov 16, 2012 at 12:01 PM, Brandon Benvie
<bran...@brandonbenvie.com>wrote:
> 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
