__proto__

[Brendan Eich]

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