classes and enumerability

Brendan Eich 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 
very high.

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).

/be

Glen Huang wrote:
> There was some heated debate on twitter too just yesterday:
> https://twitter.com/domenic/status/547146484479561730
>
> 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 
> modification?


More information about the es-discuss mailing list