On __proto__ as a magical data property

Jason Orendorff jason.orendorff at gmail.com
Wed Jul 18 13:11:39 PDT 2012

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).


More information about the es-discuss mailing list