classes and enumerability
brendan at mozilla.org
Wed Dec 24 16:26:55 PST 2014
Axel Rauschmayer wrote:
> The alternative is to treat enumerability the way ES6 treats holes:
> pretend it doesn’t exist:
That doesn't work, here or for holes. We've actually split APIs with
respect to holes, and this will mean bugs. We did make an intentional
future-trumps-past choice against holes, though.
Here and on twitter, we seem to have members of the committee on both
sides. Not good. Not saying consensus is broken and dissenters from the
draft status will throw their bodies in front of the train, but it's
worth extended discussion and (thanks again, Rick) measurement of what
can be measured.
> * 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?
The prescriptionist approach has not worked. See the Auburn study that
People use for-in without hasOwnProperty -- a lot. Some intentionally
well-used cases, no doubt -- others accidents waiting to happen.
JS has some bad defaults, requiring long-winded workarounds. Lazy
programmers will inevitably skip the workarounds. Let's not do another.
More information about the es-discuss