Sorry I got your intention wrong and glad your agreed. :) > On Dec 25, 2014, at 10:39 AM, Rick Waldron <waldron.r...@gmail.com> wrote: > > To be clear, the only conclusion to be drawn from my exercise was that there > isn't a broad pain being felt by all developers all the time, going out of > their way to explicitly define non-enumerable properties. My motivation > always begins at: how to evolve the language based on the most common > developer patterns. In the absence of a compelling hardship, I don't see the > benefit of changing the default definition semantics—but—as I my own > understanding evolves, I think I'm in agreement with Brendan and Yehuda (and > whoever else) that: enumerable in obj lit, non-enumerable in class body is > reasonable path forward. > > Rick > On Wed, Dec 24, 2014 at 9:21 PM Glen Huang <curvedm...@gmail.com > <mailto:curvedm...@gmail.com>> wrote: > Just my 2 cents: > > 1. Rick’s field test approach is epic. Encourage me to get my hands dirty. :) > > However, the conclusion I get from these tests is that not many developers > explicitly set things to be non-enumerable. This does not directly translate > to “many developers care about prototype properties being enumerable”. > > I agree with Andrea here that `hasOwnProperty` has to be taken into > consideration. Especially whether people use `hasOwnProperty` inside “for > in”. Because that’s what enumerability of class syntax will eventually > affect. Nothing else matters if I’m not wrong. (This seems to also be Allen’s > opinion) > > 2. Allen’s study addressed exactly that. > > Especially the "ENUMERATION WITH FOR…IN” chapter. And again, epic. :) > > The conclusion in the study is that not many people use “hasOwnProperty” > with “for in”. However, one thing I think is still missing is to examine that > what kinds of objects are being used with “for in”. For example, if this is > how they use “for in”: > > ``` > var defaults = { … }; > for (var key in defaults) { … } > ``` > > or > > ``` > var defaults = { … }; > var options = Object.create(defaults); > for (var key in options) { … } > ``` > > Then it should be totally fine if they don’t use “hasOwnProperty” and they > don’t adding things to Object.prototype. (I think whether they (or the libs > they use) add properties to Object.prototype should also be examined in this > case). > > Also “for in” over DOM objects should also be examined. Because enumerability > of class syntax doesn’t matter here even if they don’t use “hasOwnProperty”. > > So it pretty much comes down to this: > > Do many developers use “for in” over objects created by user created > constructors and don’t use “hasOwnProperty” when they do that. > > If the answer is “yes”, then default class syntax to non-enum is probably not > a good idea. Otherwise, it should be fine. > > I will do some tests to see if I can answer that question with some concrete > data. (probably is going to take some time, I don’t see reliable way of > testing that right now). > > > On Dec 25, 2014, at 8:56 AM, Brendan Eich <bren...@mozilla.org > > <mailto:bren...@mozilla.org>> wrote: > > > > Sorry, you can't use small-world reasoning about programming in the large, > > especially with JS on the web. for-in proliferated, before hasOwnProperty > > appeared in ES3. Even after, the burden was high enough, per that study > > Allen cited > > (http://munawarhafiz.com/research/jssurvey/GHB14-JSUsedParts.pdf > > <http://munawarhafiz.com/research/jssurvey/GHB14-JSUsedParts.pdf>). for-in > > ain't going away. > > > > If you are saying we should make class prototype methods non-enumerable in > > ES6, I agree. If you're saying it won't matter that they remain as drafted, > > enumerable, because everyone will stop using for-in. I don't buy it. If you > > are suggesting that for-in-based code won't be run on class prototypes, > > perhaps -- but that's a gamble. > > > > /be > > > > Gary Guo wrote: > >> Actually I believe that there will not be many cases that we need to use > >> for-in loop in ES6. In most cases enumerate through properties in the > >> prototype chain is not preferable. for-of Object.keys should be enough for > >> enumeration with own properties. If my assumption is correct, since we are > >> less likely to use legacy ways, we will be more able to make a change. > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > > https://mail.mozilla.org/listinfo/es-discuss > > <https://mail.mozilla.org/listinfo/es-discuss> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
