<div dir="ltr">Thanks Allen, makes sense ... but still no example where enumerability of properties and method defined in a "class" prototype is useful for ... something I cannot imagine right now.<div><br></div>
<div>Anything?</div><div><br></div><div>I understand for-of replaces ... etc etc ... for-of is not easy to polyfill though while class sugar is straight forward.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Jan 11, 2014 at 9:39 AM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Jan 11, 2014, at 9:24 AM, Andrea Giammarchi wrote:<br>
<br>
> I would like to see some Rick or David example about the "expected to be enumerable".<br>
><br>
> If that's about knowing if a class is native or not, looping with a for/in its prototype or any instance does not seem to mean anything reliable since even native methods can be redefined and made enumerable.<br>

<br>
</div>It's not just prototypes.  The same non-enumerability conventions are applied to built-in constructor properties (ie, class static methods).<br>
<div class="im"><br>
><br>
> If that's the case I would rather consider a simple `Object.isNative(generic)` proposal that would simply return true for all native things that would return `[native code]` via {}.toString.call(generic)<br>
<br>
</div>This has nothing to do with "native code".  Built-ins can be self hosted using JS code and show that code (or not) in their toString.  It's strictly a specification issue.  The spec. says that, in general, built-in methods are non-enumerable and that non=built-in methods are enumerable.<br>

<span class="HOEnZb"><font color="#888888"><br>
<br>
allen</font></span></blockquote></div><br></div>