domenic at domenicdenicola.com (2014-01-17T23:56:00.137Z)
Also true ... it's funny 'cause for ages we, developers, tried to make "ES3 classes" non enumerable so that for/in were not affected, we could extend (avoiding conflicts, etc) and now that we could define such behavior as default through a new ES6 class syntax we are "worried" that is not what developers want ... I thought the fact basically every piece of code based on `.hasOwnProperty()` check as first line of any `for/in` would be already convincing nobody wants class enumerability and indeed I usually define prototypes via defineProperties in a non enumerable way, but maybe I am the only that never wanted/needed inherited enumerability for classes. That being said the single/multiple mixin through prototype would be a problem, if done pragmatically, but it can be easily solved with `getOwnPropertyNames` ? Make classes methods/properties enumerable by default ... I am still not convinced is useful and I don't remember other OOP languages exposing classes properties within loops. Anyway, not a big deal, nothing to go nuts about ... we can all keep coding anyway.
Also true ... it's funny 'cause for ages we, developers, tried to make "ES3 classes" non enumerable so that for/in were not affected, we could extend (avoiding conflicts, etc) and now that we could define such behavior as default through a new ES6 class syntax we are "worried" that is not what developers want ... I thought the fact basically every piece of code based on `.hasOwnProperty()` check as first line of any `for/in` would be already convincing nobody wants class enumerability and indeed I usually define prototypes via defineProperties in a non enumerable way, but maybe I am the only that never wanted/needed inherited enumerability for classes. That being said the single/multiple mixin through prototype would be a problem, if done pragmatically, but it can be easily solved with `getOwnPropertyNames` ? Make classes methods/properties enumerable by default ... I am still not convinced is useful and I don't remember other OOP languages exposing classes properties within loops. Anyway, not a big deal, nothing to go nuts about ... we can all keep coding anyway. Best Regards On Mon, Jan 13, 2014 at 7:53 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > > On Jan 13, 2014, at 6:46 AM, Boris Zbarsky wrote: > > > On 1/12/14 11:57 PM, Andrea Giammarchi wrote: > >> Recap: it seems we agree classes properties and methods should not show > >> up in a for/in > > > > I should note that web developers commonly expect DOM methods/properties > to show up in for/in (and in fact often write code depending on that, > sometimes depending on the order of the enumeration). So to the extent > that we're trying to align DOM stuff with ES6 classes, we may need a > class-level switch to decide whether a particular class has enumerable > members or something. :( > > Whatever the default enumerability, you can always change it using > Object.defineProperty and you can write a utility function that will does. > Define the utility as a method on function prototype and you can say > something like: > > class Foo {}; > Foo.enumerableMethods(); > //or > Foo.nonenumerableMethods(); > > Allen > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140113/5466fbac/attachment.html>