B.3.1 The __proto__ pseudo property

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Apr 22 13:26:05 PDT 2013


then what's the point to poison
Object.getOwnPropertyDescriptor(Object.prototype,
"__proto__").set if anyone can always use __proto__ to change the chain ?

I don't understand this poisoning ... I don't see any advantage, only
problems if some library would like to drop __proto__ and use in edge case
that setter for good.

Thanks for clarifications


On Mon, Apr 22, 2013 at 1:15 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> We don't currently have the concept of an object "belonging" to a realm.
>  Functions have a realm association, but not non-function object.
>
> Object.create(parent);    //we have no way to determine if parent
> "belongs" to the same realm as Object.create.
> we also currently have no way to determine whether the caller of
>  Object.create is in the same or different realm as Object.create.
>
> someObject.__proto__  = someParent;  //the setter function from
> Object.prototype has no way to determine a realm association for someParent.
>
> let protoSetter = Object.getOwnPropertyDescriptor(Object.prototype,
> "__proto__");  //a proto setter from some realm
>
> let x = {};
> protosetter.call(x, another);    //no realm info to validate.
>
> protosetter is essentially a universal setPrototypeOf function.
>
> The only way I see to tame any aspect (for example not allowing
> Object.prototype.__proto__ = something) of __proto__ setting is via a
> [[Set]] over-ride on Object.prototype.
>
> Allen
>
>
>
> On Apr 22, 2013, at 7:29 AM, Andreas Rossberg wrote:
>
> > On 22 April 2013 15:49, Brendan Eich <brendan at mozilla.com> wrote:
> >>> However, in that case, I actually think that there is no need to have
> >>> any special poisoning semantics when reflecting __proto__ -- mainly
> >>> because the cross-realm check is already necessary in the unreflected
> >>> case: you can construct an object o in realm A with an
> >>> Object.prototype from another realm B on its proto chain. If you
> >>> deleted __proto__ on realm's A Object.prototype, I don't think it
> >>> should still be possible to assign to o.__proto__, should it?
> >>
> >> Why not, if in realm A we evaluate 'var o =
> >> Object.create(B.Object.prototype)'? You specified 'delete
> >> A.Object.prototype' happened, and A.Object.prototype is not on o's proto
> >> chain.
> >
> > My understanding of the motivation for poisoning was to enable the
> > deletion of O.p.__proto__ when configuring a realm as a means for
> > guaranteeing that no object from that realm can ever have its
> > prototype mutated. Allowing the above case would seem to shoot a hole
> > into that.
> >
> >  // Realm A
> >  delete Object.prototype.__proto__  // no messing around
> >
> >  let other = getObjectFromSomewherePotentiallyAnotherRealmB()
> >
> >  let p1 = Object.create(other, {a: {value: 1}})
> >  let o = Object.create(p1)
> >  let p2 = Object.create({})
> >  o.__proto__ = p2  // say what?
> >
> >
> >>> Whether a
> >>> difference should be made between quoted and unquoted I don't know, I
> >>> must have missed the rationale for such a move.
> >>
> >> I think we're not going to induce vomiting by making a quoted vs.
> unquoted
> >> distinction, in light of Mark's point about computed property names.
> >
> > OK, good. :)
> >
> > /Andreas
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130422/1fed093b/attachment.html>


More information about the es-discuss mailing list