<div dir="ltr">I don't see any risk around mixins for the following reasons:<div><br></div><div><ol><li>mixins are nowhere in specs so any solution is personal/ad-hoc but ...</li><li>if you use `Object.assign` you don't do that at class definition time, you do that eventually after. This possibility will be unchanged, you can still attach whatever you want as enumerable property to the class prototype once defined ... the idea here is not to not make that possible anymore, rather to have a default definition that is configurable but not enumerable (+ writable for methods and values or get/set for get/setters)</li><li>using literals to define traits is still the easiest way to go and it also define a clear line between a class and a trait. Once ES7 will have traits syntax within the class one we can assume traits are imported during class definition and, as such, will be assigned non enumerable. This would still be the least surprise in my opinion</li></ol><div><br></div></div><div>Moreover, using Object.assign for mixins is already a very poor pattern 'cause also getters and setters will be lost during the procedure, adding an extra surprise in the middle.</div><div><br></div><div>Object.assign is good to extend own properties and copy options and defatuls values, promoting or using it to define the future of traits in JS ... well, I'd personally wouldn't go for it and think about better solutions for ES7</div><div><br></div><div>Meanwhile, we should be careful to base the present (ES6) and the future based on what we used to do in ES3, hence a window to improve classses.</div><div><br></div><div>Best Regards</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 24, 2014 at 7:02 PM, Kevin Smith <span dir="ltr"><<a href="mailto:zenparsing@gmail.com" target="_blank">zenparsing@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(80,0,80);font-size:13px">```js</span><br></div><div><font color="#500050">class List extends Array {</font></div><div><font color="#500050">   itsGoingToBeEnumerable() {</font></div><div><font color="#500050">     return 'but does it have to and would you expect to?';</font></div><div><font color="#500050">   }</font></div><div><font color="#500050">}</font></div><div><span style="color:rgb(80,0,80);font-size:13px">```</span></div></div></blockquote><div><br></div></span><div>That's a good point.</div><div><br></div><div>As far as I can tell, the downside risk associated with making class methods non-enumerable centers around mixins:</div><div><br></div><div>- Legacy mixin utilities will tend to fail when given ES6 classes.</div><div>- We have no built-in function for doing proper mixins yet, and `Object.assign` won't work at all.</div><div><br></div><div>I looked through my ES6 code and found a place where I was using `Object.assign` as an simplistic mixin function.  It might be a pain to have to import a userland utility for such cases.</div><div><br></div></div></div></div>
</blockquote></div><br></div>