Inline<br><br><div class="gmail_quote">On Tue Dec 23 2014 at 10:24:06 PM Brendan Eich <<a href="mailto:brendan@mozilla.org">brendan@mozilla.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It ain't over till it's over. If we can't tweak ES6 to fix a mistake,<br>
just because process, then we're doing it wrong. OTOH the bar for any<br>
change, including what is regarded by many (but not all) as a fix, is<br>
very high.<br>
<br>
We should take advantage of es-discuss to debate the crucial question,<br>
which is not whether enumerable prototype methods are the rule or<br>
exception -- as Rick said, for built-ins (but not all DOM methods),<br>
non-enumerable is the common case; for user-defined classes prior to ES5<br>
and Object.defineProperty, enumerable is the norm.<br>
<br>
This is true in the rule/exceptions/confusion sense we all know and hate.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The question is: what should ES6 classes choose as the default? What's<br>
the most useful default, independent of various backward-looking<br>
consistencies? What, if the future is bigger than the past, would be best?<br></blockquote><div><br></div><div>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?). </div><div><br></div><div>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? </div><div><br></div><div>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:</div><div><br></div><div>- Compiled a list of 600 modules that npm shows as the most depended on (<a href="https://www.npmjs.com/browse/depended">https://www.npmjs.com/browse/depended</a>, pages 1-10). </div><div>- I created a script that installed all 600 modules</div><div>- 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)</div><div>- 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. </div><div>- Read the source of each file, line by line, counting occurrences of the following: </div><div><div>  - enumerable: false, </div><div>  - enumerable:false,</div><div>  - 'enumerable': false</div><div>  - 'enumerable':false</div><div>  - "enumerable": false</div><div>  - "enumerable":false</div></div><div><br></div><div>Here are all the occurrences, marked by file and line number: <a href="https://gist.github.com/rwaldron/8989d6e7cd7b2f6bfdbb">https://gist.github.com/rwaldron/8989d6e7cd7b2f6bfdbb</a></div><div><br></div><div>Here is the summary: </div><div><div>Total Files Read:  11038<br></div><div>Files Containing Explicit 'enumerable: false':  149</div><div>Occurrences of 'enumerable: false' (and variants): 206</div></div><div><br></div><div><br></div><div>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. </div><div><br></div><div><br></div><div>Rick </div></div>