Rick Waldron (2013-09-26T22:03:55.000Z)
domenic at domenicdenicola.com (2013-10-13T02:28:16.807Z)
On Thu, Sep 26, 2013 at 5:43 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > On Sep 26, 2013, at 1:59 PM, Brendan Eich wrote: > > > @ is the new dunder -- dunder at -- dat. > > > > Among the no-symbol proposals, I like this best. (GUIDs, shudder.) > > > > /be > > I shudder to say this, having just finished my third complete redo of > Symbols in the ES6 draft, but I also like this proposal a lot. > > I think I had a blind spot about string literals being accepted as methods > names in object literals and classes. But this would be a significant > simplifications that retains almost all the benefits of Symbols. And it's > completely polyfillable. > > A couple more thoughts: > > Symbol-keyed property definitions were the primary motivator for "computed > property names" in object literals and classes. They could also go away > for ES6 -- another simplification. > > Perhaps rather than the function conventions for "@" properties , we > should considerhaving them always be getter properties. But, I haven't yet > sold myself on either one as being better. > > A negative is that it was decided that concise methods definitions create > enumerable properties and I don't think we really want these showing up in > for-in enumerations. Maybe we would want to revisit that decisions or at > least make an exception for concise methods (or accessors) defined using > explicit string literal names. > The whole point of making them enumerable was to undo a decision to that made an exception for concise methods—that applies to properties that were defined with string literal names ( https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-09/sept-18.md#concise-method-definition-revisited ) ```js var o = { "method": function() {} }; ``` Should behave exactly the same as ```js var o = { "method"() {} }; ``` Because existing code will expect this to work (using lodash library as an example, but it could be any library code that uses for-in): ```js _.extend(Some.prototype, o); ``` Which user code expects will result in: ```js Some.prototype.method === o.method; // true ```