No surprise here, but I also support using "@" methods. I'm also in favor of making methods non enumerable by default. This makes them more consistent with what we have in ES today. My only concern is that methods in the DOM are enumerable and changing that seems like a high risk.
On Thu, Sep 26, 2013 at 2:43 PM, Allen Wirfs-Brock <[email protected]> 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. > > Allen > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss -- erik _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
