On Nov 8, 2011, at 11:48 AM, Felipe Gasper wrote: > Actually, have you ever seen a use case of wanting to prevent iteration > through inherited properties *other* than Object.prototype? (Besides using > for..in on Array objects.)
Sure. People make "classes" by defining function C(){} and decorating C.prototype.method1 = function(...){...}, etc. A for-in loop on (new C) will see all the methods, unlike the case with built-in constructors. That is an unwanted abstraction break: we should support abstracting over user-defined and built-in functions. > All of the examples I’ve ever seen of the problems that ensue from for..in > iteration and prototypes stem from extending Object.prototype. Why not, then, > specifically address that problem rather than preventing all iteration > through inherited properties? I think you're focusing too narrowly. I agree with Jake: make a copy into a single object, and access it (if it's a config dictionary) with a stylized API. Sounds like you could make YUI happy that way. Separately, I think I'll propose for own(...) based on CoffeeScript's for own in/of loops. That seems more important for the long run than any API elaboration beyond Object.prototype.hasOwnProperty. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss