Inline On Tue Dec 23 2014 at 10:24:06 PM Brendan Eich <[email protected]> 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 following: - enumerable: false, - enumerable:false, - 'enumerable': false - 'enumerable':false - "enumerable": false - "enumerable":false Here are all the occurrences, marked by file and line number: https://gist.github.com/rwaldron/8989d6e7cd7b2f6bfdbb 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
