Analog to Object.getPropertyDescriptor() for *changing* a property value?
allen at wirfs-brock.com
Thu Jun 23 03:29:31 PDT 2011
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss