Comments on Sept Meeting Notes
erik.arvidsson at gmail.com
Thu Sep 26 15:02:58 PDT 2013
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
On Thu, Sep 26, 2013 at 2: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.)
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss