classes and enumerability

Brendan Eich 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: 
> 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?

The prescriptionist approach has not worked. See the Auburn study that 
Allen cited:

http://munawarhafiz.com/research/jssurvey/GHB14-JSUsedParts.pdf

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.

/be


More information about the es-discuss mailing list