On __proto__ as a magical data property
oliver at apple.com
Wed Jul 18 13:15:38 PDT 2012
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.
On Jul 18, 2012, at 1:11 PM, Jason Orendorff <jason.orendorff at gmail.com> wrote:
> On Wed, Jul 18, 2012 at 4:35 AM, Andreas Rossberg <rossberg at 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).
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss