Analog to Object.getPropertyDescriptor() for *changing* a property value?
brendan at mozilla.com
Tue Jun 21 14:01:08 PDT 2011
On Jun 21, 2011, at 1:50 PM, Axel Rauschmayer wrote:
> That sounds like the opposite argument you are making with regard to the hypothetical |here|:
>> BTW I do not agree we can or should try to reserve 'here' or expose the method's "home object" -- that breaks abstractions built using prototypes. 'super' does not, because it always goes to the [[Prototype]] of the object in which the method was defined.
No, the arguments are close cousins, in no way opposed.
You should not in general mutate shared prototype state via one of N delegating objects. It leads to trouble.
You should not depend on which of M prototype objects along the chain holds a method. Similar trouble with scaling M, evolving the program to increase M by interposing a new prototype which might inject a shadowing method for good reason, and so on.
> The prototype seems to be the best location for shared data (such as the number of instances of a class).
Counting instances can't be done without leaking GC non-determinsm, so this is a bogus example. Can you come up with another? Shared mutable state in prototypes that is visibly mutable by means of a reference to one of N delegating objects is usually a bug.
More information about the es-discuss