Axel Rauschmayer axel at rauschma.de
Thu Jan 9 03:21:17 PST 2014

I’m still really unhappy about enumerability in ECMAScript. I find it frustratingly inconsistent:

* At the moment, only Object.keys and the for-in loop are affected by it.
* In ECMAScript 6, Object.assign will also ignore non-enumerable properties.
* Built-in prototype methods are non-enumerable, as is property `length` of arrays.
* In ECMAScript 6, prototype methods created by classes are enumerable, the prototype method `constructor` is non-enumerable (as it is by default in all functions).

I’ve seen various explanations for what enumerability is:

1. Something that won’t matter in the long run. But then why are we introducing new constructs that take it into consideration?
2. Something that one has to do properly so that old code doesn’t break. Here, it’d be helpful to be concrete: where can this happen? The obvious case is for-in for instances of built-in constructors.
3. Signaling an intent of sharing. But what does that mean in practice? Why are built-in methods different from user-defined methods in this regard?
4. A way of marking a method as private. Again: why the divergence between built-in methods and user-defined methods?

I think it would really help the design of ECMAScript going forward if we had a definitive and complete explanation of what enumerability is now and what it should be in the future. I’m trying to make sense of it and to explain it to others and continue to fail.


Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

More information about the es-discuss mailing list