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 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 > -- Dr. Axel Rauschmayer [email protected] twitter.com/rauschma home: rauschma.de blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
