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

Brendan Eich brendan at
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 mailing list