classes and enumerability

Rick Waldron waldron.rick at gmail.com
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.

Rick
On Wed, Dec 24, 2014 at 9:21 PM Glen Huang <curvedmark at 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 <brendan at 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). 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 mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> 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/20141225/3d16fd5d/attachment-0001.html>


More information about the es-discuss mailing list