JSC migrating __proto__ to accessors did not add any power, if anything it removed/reduced power. The old __proto__ was an extraordinarily magical property that existed on every object. It was not possible to remove/block it at all. So anyone could make an accessor or function or implicit conversion that could arbitrarily change the prototype of an object.
--Oliver On Jul 18, 2012, at 1:11 PM, Jason Orendorff <jason.orendo...@gmail.com> wrote: > On Wed, Jul 18, 2012 at 4:35 AM, Andreas Rossberg <rossb...@google.com> wrote: >> I agree with that. I'm not quite convinced that there are relevant security >> implication with an accessor semantics either. > > If we want to be sure we're not adding any power here, the __proto__ > setter should simply check that the receiver actually has the original > __proto__ property; if not, it should throw. > > That would be weird, but safe, and the weirdness would be isolated in > a section of the specification under the heading "__proto__ setter" in > an annex. Containment! > >> I also don't think that array length counts as proper precedence. > > Speaking as an implementor, I see array length as a precedent to be > avoided. SpiderMonkey still doesn't implement all its quirks. > > I'm not surprised Waldo's experiment with accessor __proto__ went > smoothly. That's because __proto__ as an accessor property almost > makes sense. > > Specifying an accessor property--plus a single special case for > ObjectLiterals, which we can handle in the front end--will make less > work and a nicer spec (that is, looser coupling, better isolation of > special cases). > > -j > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
