Rick Waldron (2013-09-26T22:03:55.000Z)
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
)

var o = {
  "method": function() {}
};

Should behave exactly the same as

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):

_.extend(Some.prototype, o);

Which user code expects will result in:

Some.prototype.method === o.method; // true


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/97b20970/attachment.html>
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
```