>/ Whether you personally use it, for-in is a reality. Introspection of
/>/ objects happens, so if you ship a library that's putting meta-level
/>/ properties into objects it needs to make them non-enumerable to be robust
/>/ in the face of client code that uses for-in but isn't prepared to
/>/ understand the meta properties.
/>/
/>/
/Is there a concrete example which shows how enumerability of meta-level
properties would present a problem for such code? That might be convincing.
There are all kinds for-in uses which don't expect meta-level hooks. For
example this "isEmpty" function to test whether an object contains any
entries:
js```
function isEmpty(o) {
for (var k in o) return false;
return true;
}
```
In this case I doubt @iterator or @toStringTag should be visible. (And I
know there a better ways to test for empty objects, but for-in testing
is common enough...)
- André
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
