On Jun 23, 2011, at 4:54 AM, Axel Rauschmayer wrote: >> How about this? You have a bunch of local variables in various functions >> referencing different objects. But by some obscure yet legal means you use >> one such reference to mutate the prototype object they share in common, so >> all the others appear to be mutated too. >> >> This is not inherently "evil", but it's usually a bug. Usually the other >> different objects do not wish to be mutated so indirectly, and the users of >> their properties (own and delegated) in those various functions may not be >> prepared for such a change. > > So you are mainly worried about mutating methods?
No, any data property. > My main concern is encapsulation: If you have class methods, I would want to > give them the option of having class state. I want the same rules that hold > for the object level (state + behavior) to hold for the meta-object level. The prototype is not the class. > >> Consider monkey-patching. You want to add value to a shared prototype, but >> you might break for-in loops. Ok, that can be solved with ES5 >> Object.defineProperty -- but not if the mutation breaks some other invariant. > > I would probably never use for-in loops in ES.next. That does not address the general problem. Please read the whole sentence including the part I wrote after the "--". /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
