> It is indeed a just-so story, but the idea is that built-ins have intersting > data properties (predefined and possibly user-defined) but the methods are > not "interesting" to for-in users.
My impression has always been that enumerability was mainly introduced to “fix” for-in [1] – it only affects for-in (apart from Object.keys). And it hides the “length” data property in array instances, so that for-in only iterates over array indices (obviously, unless one adds more enumerable properties). I’ve always found it difficult to formulate a good rule of thumb for enumerability, apart from “ensures that for-in works”. Object.keys() also reacts to enumerability, but in a way that has little to do with for-in (given that it only operates on own properties). Furthermore, I find myself frequently using Object.getOwnPropertyNames, e.g. to find out what methods a constructor’s prototype has. And that method should be the one that is much less frequently used, according to the ES naming conventions. So, the current narrative for enumerability seems to me a bit disjointed and mostly about for-in. Given that for-in is on its way out and given that inherited data properties are rarely a good idea, would it make sense to change that narrative? [1] http://www.2ality.com/2011/07/js-properties.html -- Dr. Axel Rauschmayer [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
