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 <[email protected]> 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 <[email protected]> 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). 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 > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
