> 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? 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. > 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. > It's occasionally useful to do AOP on shared prototypes. My point is that you > ought to address them directly by their true names (Array.prototype, e.g.; > not Object.getPrototypeOf(someArray)). Right, the latter looks really bad. I would rely that the same kind of unique name that took me to a class method (via "this") will also take me to a class variable (also via "this"). If I invoke the method via "this", e.g. Array.prototype.myClassMethod(), then this.myClassVariable would *still* work. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
