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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
