classes and enumerability

Andrea Giammarchi andrea.giammarchi at
Wed Dec 24 16:21:06 PST 2014

I'm sorry Rick, that's a great analysis but this is also how I see it,
metaphorically speaking:

"most cars in the world use wheels 'cause we don't know better and that's
how it always worked"

To be more explicit, here things I would have exepceted anyway:

Find out that developers tried to make things work down to ES3 and IE <= 8

Finding that developers didn't have native way to create classes before so
they used known ES3 patterns

Finding that old ES3 based class like architectures never bothered about
enumerablility since JSLint does not even accept for/in without a
hasOwnProperty check, these same libraries never bothered about getters and
setters inheritance too though (most of them)

Find out that Mr. D talked about enumerability as one of the bad part
people got used to but new comers will always smash their code against

Find out that someone actually bothered about this, in order to have
cleaner intent and expectations, without basing the code over ES3 and
understanding and using ES5 at its best ... these probably understand
getters and setters too, everyone else should be left out of the equation,

I'd also count how many `hasOwnProperty` checks are out there in the wild
because of all previous historical facts ... and re-read the analysis
since, as others said already, are we considering the way the past forced
to write things instead of considering the way developers would like things
to be?

Back to my first question: why would you ever want a method in a class be

Hope you got my point, thanks in any case for providing more data to think


P.S. this is mostly off topic but I find absolutely hilarious that Custom
Elements and document.resgisterElement accept a prototype property that
needs an object created through Object.create and a descriptor that for
lazyness will make ewverything non enumerable and actually even non
configurable and non writable ...


var MyElement = document.registerElement(
    prototype: Object.create(
      HTMLElement.prototype, {
      myCallback: {value: function() {


going this direction we'll have in the near future custom elements with
nothing enumerable, opposite to current Web IDL standard, and JS user
classes and subclasses with everything enumerable, opposite to JS native
classes ... can I call sheganigans here ? :-)

On Wed, Dec 24, 2014 at 10:27 PM, Rick Waldron <waldron.rick at>

> Inline
> On Tue Dec 23 2014 at 10:24:06 PM Brendan Eich <brendan at>
> wrote:
>> 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?
> Put in these terms, I still think that maintaining status quo makes sense.
> The future _is_ bigger than the past and this can be addressed via
> annotations (maybe even in ES7?).
> It seems worthwhile to mention non-enumerability has its own problems:
> recall that Array.prototype.contains was recently renamed to
> Array.prototype.includes exactly because the built-in is non-enumerable by
> default. It could've been argued that this was a good reason to break with
> that norm and make built-ins enumerable by default. That of course is a
> non-starter—so why is breaking "enumerable by default" for user defined
> classes under consideration?
> Non-enumerability can still be achieved, it's not pretty (it downright
> sucks), but most user code simply doesn't go out of its way to explicitly
> define properties as non-enumerable:
> - Compiled a list of 600 modules that npm shows as the most depended on (
>, pages 1-10).
> - I created a script that installed all 600 modules
> - Confirmed installation by attempting to require all of them. Three
> created issues when require'ing, but otherwise all modules loaded
> (typescript, fstream-ignore, fis-parser-less)
> - Globbing "node_modules/**/*.js" produced 35371 files, so do a naive
> filter for paths with "test" in it (assume this just a test file, whether
> that's correct or not, as we'll see: it doesn't matter). Also only look at
> a file once by tracking the actual module file path and not the complete
> path. This brings the number down to 11038 files.
> - Read the source of each file, line by line, counting occurrences of the
> following:
>   - enumerable: false,
>   - enumerable:false,
>   - 'enumerable': false
>   - 'enumerable':false
>   - "enumerable": false
>   - "enumerable":false
> Here are all the occurrences, marked by file and line number:
> Here is the summary:
> Total Files Read:  11038
> Files Containing Explicit 'enumerable: false':  149
> Occurrences of 'enumerable: false' (and variants): 206
> I was ready to concede until I did this exercise, but I'm holding my
> position that the default should remain enumerable. A vocal minority
>  shouldn't trump the reality of programmer's expectations.
> Rick
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list