classes and enumerability

Andrea Giammarchi andrea.giammarchi at
Wed Dec 24 06:26:49 PST 2014

I've replied to Rick privatly by accident but regardless what I've written
there, which is basically agereing with Brendan on the following sentence:
> It ain't over till it's over. If we can't tweak ES6 to fix a mistake,
just because process, then we're doing it wrong.

and describe why his example can be done anyway (using getOwnPropertyNames
instead of keys) and why object literals shouldn't be affected indeed ...
there is a very strong point to me that is the main bummer ...

class List extends Array {
   itsGoingToBeEnumerable() {
     return 'but does it have to and would you expect to?';

Not only being fresh new sugar, `class` could bring more than what basic
ES3 prototype assignment has done for 15+ years, forcing historically every
developer to be worried about doomed `for/in` loops and asking randomly any
sort of native methods in specs so that would feel safer 'cause not
enumerable, given the ability to finally subclass natives will mess up
expectations even more: an instanceof Array that could have methods in the
loop and cannot be used as sparse array ... this is just an example that
will doom again subclassing and loops ... does it have to be like this ?

Subclassing is planned and basically unshimmable ... why should we keep
bringing further old gotchas instead of finally cleaning up through a new
syntax that is fully compatible with ES5 when it comes to transpiled
prototype properties definition ?

Please let's make `class` developer friendly, giving them the option to
fallback to classical prototype literal object definition, when and if
needed, providing a better pattern for modern architectures built on top of
ES6, 7 and others.

Thanks for consideration.

Best Regards

On Wed, Dec 24, 2014 at 10:32 AM, Glen Huang <curvedmark at> wrote:

> Nothing. I forgot about those methods, and Kevin also kindly reminded me.
> Thanks for letting me know. :)
> > On Dec 24, 2014, at 5:22 PM, Brendan Eich <brendan at> wrote:
> >
> > ES5 has Object static methods for getting all own property names,
> > enumerable or not. Also walking prototype chain. What's the problem
> > you're thinking of, exactly?
> >
> > /be
> >
> > Glen Huang wrote:
> >>
> >> I was saying that a feature like lightweight traits is probably
> >> impossible to desugar to es5, if class syntax makes properties and
> >> methods non-enum.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list