classes and enumerability
brendan at mozilla.org
Tue Dec 23 19:23:55 PST 2014
It ain't over till it's over. If we can't tweak ES6 to fix a mistake,
just because process, then we're doing it wrong. OTOH the bar for any
change, including what is regarded by many (but not all) as a fix, is
We should take advantage of es-discuss to debate the crucial question,
which is not whether enumerable prototype methods are the rule or
exception -- as Rick said, for built-ins (but not all DOM methods),
non-enumerable is the common case; for user-defined classes prior to ES5
and Object.defineProperty, enumerable is the norm.
This is true in the rule/exceptions/confusion sense we all know and hate.
The question is: what should ES6 classes choose as the default? What's
the most useful default, independent of various backward-looking
consistencies? What, if the future is bigger than the past, would be best?
In the twitter thread, @wycats and I take on the idea that consistency
with object literals is required. I hope that's not controversial. Class
bodies are *not* object literals, in spite of sharing some sub-notation
(method shorthanding, mostly).
Glen Huang wrote:
> There was some heated debate on twitter too just yesterday:
> Just wondering, is es6 class frozen? In those tweets Brendan proposed
> "enum in obj lit, not in class”. Looks like class is still open for
More information about the es-discuss