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. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
