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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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 < >>> [email protected]> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
