classes and enumerability

Axel Rauschmayer axel at rauschma.de
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: 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 <zenparsing at gmail.com> 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 rauschma.de
rauschma.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141224/28621242/attachment.html>


More information about the es-discuss mailing list