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 http://www.wirfs-brock.com/allen/posts/228 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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
