On Sep 11, 2007, at 1:47 PM, Kris Zyp wrote: > __proto__ breaks abstraction boundaries in the language -- it's just > > Hiding for the sake abstraction is more valuable than introspective > visibility? I disagree, at least with JavaScript, IMHO JS's > introspective nature is one of it's greatest strengths. Is there a > precedence for this in other languages? Java is big on abstractions > but inheritance is still introspectable (I realize that is not > completely the same). And I believe that Self, the closest > relative, makes the proto available throught .parent* property (I > could be wrong about that).
Self has *-suffixed slots that constitute multiple prototypes per object. Yeah, JS is reflection-happy, or was. Some of it was distorted due to minimization (no activation reflection, so fun.caller) and that wasn't standardized. And ES1 intentionally censored activation object reflection, so much so that when closures were standardized in ES3, the bug where |this| inside a nested function does not match the outer function's |this| when the inner is called from the outer inadvertently bit. Reflection is two-edged. It breaks abstraction, removes some theorems for free, and with mutation it can do a lot of damage (sometimes a good thing ;-). A read-only __proto__ is hazardous for those factory closures that hide the created object's prototype. Without __proto__, you can't get at the prototype, which means you can enforce some integrity properties about names not being found rather than being found in the proto. A read-write __proto__ is unthinkable (and in SpiderMonkey, complete with cycle detection :-P). > security threat depends on the details of the environment: whether > > Hasn't that security threat been evaluated by the years that this > property has already been available? It has, and while __proto__ has been used in some Mozilla PoCs over the years, it wasn't that big a deal. It was never exploited in the wild that we know of. But it added attack surface and it exacted a toll. I am not proposing it for ES4. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
