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: https://twitter.com/sebmarkbage/status/547156703104753664 > "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 <[email protected]> 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 [email protected] rauschma.de
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
