__proto__

[Garrett Smith]

On 9/11/07, Lars T Hansen <lth at acm.org> 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 <kriszyp at xucia.com> 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
> > Es4-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es4-discuss
> >
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>


--
Programming is a collaborative art.


-- 
Programming is a collaborative art.