classes and enumerability

Rick Waldron waldron.rick at
Wed Dec 24 13:27:44 PST 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list