Flexibility of shared state? Are you really corrupting the state of defaults at runtime? Do you really want changes to your default options to propogate to all objects extending the defaults?
This seems like a right pain in the ass to debug/maintain? On Nov 8, 2011 8:12 PM, "Luke Smith" <[email protected]> wrote: ------------------------------ Brendan Eich <[email protected]> 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 ... 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 a... 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
<<compose-unknown-contact.jpg>>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
