classes and enumerability

Rick Waldron waldron.rick at
Wed Dec 24 18:39:26 PST 2014

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.

On Wed, Dec 24, 2014 at 9:21 PM Glen Huang <curvedmark at> 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 <brendan at> 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 (
> 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 at
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list