name anonymous functions on property assignments

Benjamin Gruenbaum benjamingr at gmail.com
Sun Jul 26 20:24:23 UTC 2015


Babel does not shim this deliberately, it is "impossible enough" as it is:
see https://github.com/babel/babel/issues/2080

Defined in
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-object-initializer-runtime-semantics-propertydefinitionevaluation
you can see that if it's a symbol it sets the function name to a symbol.

To make this extra clear - it does "Let description be name’s
[[Description]] value." and then `defineProperty`s it with that, this is
specified in
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-setfunctionname

On Sun, Jul 26, 2015 at 11:17 PM, Jordan Harband <ljharb at gmail.com> wrote:

> What is the function's name if the computed object literal key is a
> Symbol? ie, what does the following output:
>
> ```js
> const sym = Symbol('something');
> const o = {
>     [sym] () {}
> };
> console.log(o[sym].name);
> ```
>
> Currently it appears Babel outputs an empty string for this case.
>
> If the current spec handles symbols just fine in this way, why would "the
> possibility that the property key is a symbol" be a reason for an
> expression form not to set the "name" property?
>
> On Sun, Jul 26, 2015 at 1:12 PM, Benjamin Gruenbaum <benjamingr at gmail.com>
> wrote:
>
>> I just want to point out that Bergus (OP) informed me that the assignment
>> behavior happens in computed object literal keys. So:
>>
>> ```js
>> let o = {
>>      ["fn" + "name"] () {}
>> }
>> o.fnname.name; // fnname
>> ```
>>
>>
>>
>>
>> On Sun, Jul 26, 2015 at 10:55 PM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> with all due respect Allen, I'm completely against magic-function-name
>>> assignment for various reason and leaking ain't one.
>>>
>>> What could you assign in ES6 that cannot be retrieved anyway through
>>> getOwnPropertySymbols and getOwnPropertyNames ? A triple-magic private
>>> Proxy handler or what?
>>>
>>> I mean, the moment you could access that method is the moment it could
>>> leak with or without a name, right?
>>>
>>> Just curious about what you had in mind, again I agree having this in is
>>> a no-go.
>>>
>>> Best Regards
>>>
>>> On Sun, Jul 26, 2015 at 8:48 PM, Allen Wirfs-Brock <
>>> allen at wirfs-brock.com> wrote:
>>>
>>>>
>>>> On Jul 26, 2015, at 5:11 AM, Benjamin Gruenbaum wrote:
>>>>
>>>> > In theory this sounds like a cool idea, I didn't even know variable
>>>> assignments named functions.
>>>> >
>>>> > The only issue I see here is how we're now differentiating assignment
>>>> by where it happens - what if the property is computed? As far as I know
>>>> function names are more constrained (like variable names) in what they can
>>>> be. Object properties may contain characters that function names may not.
>>>>
>>>> the possibility that the property key is a symbol is a primary reason
>>>> that this expression form does not set the `name` property.
>>>>
>>>> There may also be security concerns.  The `name` property potentially
>>>> leaks via the function object the name of the variable it is initially
>>>> assigned to.  But there isn't much someone could do with a local variable
>>>> name, outside of  the originating function.  But a leaked property name
>>>> potentially carries a greater capability.
>>>>
>>>> Allen
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150726/adf2803a/attachment.html>


More information about the es-discuss mailing list