Why we need to clean up __proto__

Mark S. Miller erights at google.com
Thu Dec 29 15:00:34 PST 2011

Hi David, that's a good point. ES-next will have three modes, IIRC
currently called non-strict, strict, and extended. (ES5 and ES-next
non-strict is effectively an "ES3 compatibility mode" and ES-next strict is
effectively an "ES5-strict compatibility mode".) As with ES5's non-strict
vs strict, these three modes are opt in per code, not per heap, and so can
only condition code properties.

{__proto__:...} having a magic meaning is per code, and so can and should
be conditioned on mode. I think it should only be allowed to be magic in
non-strict mode. In strict code and extended code, it should either not be
magic or it should be prohibited -- I'm not sure which. As with nested
named functions, it would then help if current ES5 implementations did not
threat this as magic in ES5 strict code, to prepare the ground for ES-next.

I will extend the proposal accordingly. Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111229/8755d3b9/attachment.html>

More information about the es-discuss mailing list