<div dir="ltr">I'm sorry Rick, that's a great analysis but this is also how I see it, metaphorically speaking:<div><br></div><div>"most cars in the world use wheels 'cause we don't know better and that's how it always worked"</div><div><br></div><div>To be more explicit, here things I would have exepceted anyway:</div><div><br></div><div>Find out that developers tried to make things work down to ES3 and IE <= 8 engines</div><div><br></div><div>Finding that developers didn't have native way to create classes before so they used known ES3 patterns</div><div><br></div><div>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)</div><div><br></div><div>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</div><div><br></div><div>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, IMO</div><div><br></div><div>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?</div><div><br></div><div>Back to my first question: why would you ever want a method in a class be enumerable?</div><div><br></div><div>Hope you got my point, thanks in any case for providing more data to think about.</div><div><br></div><div>Cheers</div><div><br></div><div><br></div><div>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 ... </div><div><br></div><div>```js</div><div><br></div><div><pre style="overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;margin-top:0px;margin-bottom:0px;line-height:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal;word-break:normal;color:rgb(51,51,51)"><span class="" style="color:rgb(167,29,93)">var</span> MyElement <span class="" style="color:rgb(167,29,93)">=</span> <span class="" style="color:rgb(0,134,179)">document</span>.registerElement(
  <span class="" style="color:rgb(223,80,0)"><span class="" style>'</span>my-element<span class="" style>'</span></span>,
  {
    prototype<span class="" style="color:rgb(167,29,93)">:</span> <span class="" style="color:rgb(0,134,179)">Object</span>.create(
      HTMLElement.<span class="" style="color:rgb(0,134,179)">prototype</span>, {
      myCallback<span class="" style="color:rgb(167,29,93)">:</span> {<span class="" style="color:rgb(121,93,163)">value</span>: <span class="" style="color:rgb(167,29,93)">function</span>() {
      }</pre></div><div>```</div><div><br></div><div>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 ? :-)</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 24, 2014 at 10:27 PM, Rick Waldron <span dir="ltr"><<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Inline<br><br><div class="gmail_quote"><span class="">On Tue Dec 23 2014 at 10:24:06 PM Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">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></span><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" target="_blank">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" target="_blank">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><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Rick </div></font></span></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>