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

Axel Rauschmayer axel at
Thu Jun 23 04:42:01 PDT 2011

I guess my argument goes like this:
- If the prototype of an instance loosely corresponds to a class, why shouldn’t we have class variables/class state?
- If the location for reading data is abstracted over, why isn’t the location for writing data?

On Jun 23, 2011, at 12:29 , Allen Wirfs-Brock wrote:

> On Jun 21, 2011, at 9: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.
>> The prototype seems to be the best location for shared data (such as the number of instances of a class). Wouldn’t you also want to abstract from the exact location of such a property?
> Behaviorally, you shouldn't care how an object is implemented.  Whether a particular property is implemented as an own property or is inherited from a prototype is an implementation detail that should be irrelevant to client code that is using an object.  Such implementation details should be, at least conceptually, encapsulated by the object.  
> If you are dynamically inspecting or modifying details of the implementation of an object you have moved into the realm of reflection.  Object.getPrototypeOf, Object.getOwnPropertyDescriptor, etc. are reflection operations.  Generally it is poor practice to design an object such that client code needs to enter the domain of reflection to interact with the object.  If client code uses these operations it is breaking implementation encapsulation. 
> One of the reason that the reflection functions added by ES5 are defined on Object rather than Object.prototype is to avoid polluting the public interface of every object with additional reflective operations over and beyond the legacy ones already defined in ES1-3. Arguably, even that separation isn't enough as Object really is in the application layer of the system rather than the reflection layer.  In the long run it would be good if we could  further separate the reflection layer by migrating to a Mirrors-based reflection model.  See my series of blogs post about Mirrors for JavaScript for more details.
> We probably still need to add some reflection methods to Object.  defineMethod is one strong candidate.  However, we really should be quite careful about what goes there as it is just too easy to use such Object.* functions to violate an object's implementation encapsulation.
> Allen

Dr. Axel Rauschmayer

axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list