Analog to Object.getPropertyDescriptor() for *changing* a property value?

Axel Rauschmayer axel at rauschma.de
Thu Jun 23 04:54:16 PDT 2011


> 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

axel at rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com





More information about the es-discuss mailing list