classes and enumerability

Axel Rauschmayer axel at
Wed Dec 24 11:38:50 PST 2014

The alternative is to treat enumerability the way ES6 treats holes: pretend it doesn’t exist:

* Use `Reflect.ownKeys`, `Object.getOwnPropertyNames`, `Object.getOwnPropertySymbols` instead of `Object.keys`.
* Don’t use the `for-in` loop (an easy one…)
* Change `Object.assign` so that it considers all properties, not just enumerable ones.
* The properties of class prototypes remain non-enumerable.
* I’m unsure about new built-in instance prototypes. For consistency’s sake, one may want to make them non-enumerable. But how would they be different from a library?

Quoting Sebastian Markbåge:

> "enumerable" is just one of an infinite number of categories you might want to filter on. It's a hack and should die.

Would this approach have any disadvantages?

> On 24 Dec 2014, at 19:02, Kevin Smith <zenparsing at> wrote:
> ```js
> class List extends Array {
>    itsGoingToBeEnumerable() {
>      return 'but does it have to and would you expect to?';
>    }
> }
> ```
> That's a good point.
> As far as I can tell, the downside risk associated with making class methods non-enumerable centers around mixins:
> - Legacy mixin utilities will tend to fail when given ES6 classes.
> - We have no built-in function for doing proper mixins yet, and `Object.assign` won't work at all.
> I looked through my ES6 code and found a place where I was using `Object.assign` as an simplistic mixin function.  It might be a pain to have to import a userland utility for such cases.

Dr. Axel Rauschmayer
axel at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list