Re: for..in, hasOwnProperty(), and inheritance

[Luke Smith]

Brendan Eich November 8, 2011 11:59 AM 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. I believe people decorate a class prototype directly because they always have, and because defineProperties wasn't available for them to declare prototype methods as not enumerable, not because they explicitly want class proto methods to be enumerable. Can you elaborate on "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. Copying loses the benefit of shared defaults via prototype.  I would rather see a method to flatten an object before enumeration than lose the flexibility of shared state. Luke

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss