On 9/11/07, Lars T Hansen <[EMAIL PROTECTED]> wrote: > On the one hand, __proto__ is another potential security hole, and it > prevents implementations from sharing prototype objects among multiple > documents -- the link may be read-only but the object isn't. Function > B called from function A with object O may hack O.__proto__ and A can > do nothing about it; suddenly all O-like objects in the system act > differently. > > On the other hand, Constructor.prototype is generally available for > any Constructor, so it's hard to see what the real damage is -- it's > not obviously worse than some other aspects of the language. >
What I've found is that it's always giving wrong constructor property with inheritance chains. A <-- B <-- C c = (new C).constructor;// A So to do this, I can use a chaining technique to hardcode the inheritance structure reading __proto__ or using hand-rolled constructor chaining, but then that requires that clients who try to get the constructor build their inheritance with the same approach that I do, and get an enumerable constructor property on their class as a side effect. The chaining technique was published many years ago by Kevin Lindsey and used by some popular libraries like YUI. How about a constructor property on the function instance? > On the third hand, some implementations may have specialized objects > for which no Constructor is available and for whom keeping > [[Prototype]] unavailable is desirable. Similarly, some toolkits may > have private prototype objects that are not available to client code > because the constructor is hidden in a lexical scope (ES3) or > package/namespace (ES4). > Could they make these private for their class? Is [[Get]] modified to exclude private members in ES4? How is prototype inheritance different than shadowing static members in Java? Are private static members a security problem in Java? Here's an example showing how to use __proto__ to get the constructor. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Property_Inheritance_Revisited:Determining_Instance_Relationships __proto__ makes the language more transparent. > Introspection is great, but it assumes a lot about how trust works in > the environment. > > --lars > > > On 9/11/07, Kris Zyp <[EMAIL PROTECTED]> wrote: > > > The alternative above would standardize read-only __proto__, which would > > > make that property no longer implementation-specific. But of course we > > > have no proposal to do that. > > I realize this wasn't really the main subject... but could the __proto__ > > property be defined in the spec (as readonly)? I would love to see that > > property standardized. > > Kris > > > > _______________________________________________ > > Es4-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es4-discuss > > > _______________________________________________ > Es4-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss > -- Programming is a collaborative art. -- Programming is a collaborative art. _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
