classes and enumerability
waldron.rick at gmail.com
Wed Dec 24 13:27:44 PST 2014
On Tue Dec 23 2014 at 10:24:06 PM Brendan Eich <brendan at mozilla.org> 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 (
https://www.npmjs.com/browse/depended, 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
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...
More information about the es-discuss