Why we need to clean up __proto__

Brendan Eich brendan at mozilla.com
Fri Dec 30 14:24:16 PST 2011

I don't think __proto__-supporting implementations will do anyone any favors by banning the special meaning of __proto__ in ES5 strict mode. The likeliest outcomeis further non-adoption of ES5 strict mode by developers, who already avoid it because of deoptimization effects.

In particular, without an alternative literal form such as

  null <| {...}

(the ... is meta), removing support for magic __proto__ in object literals simply prevents "use strict"; from being added to code that makes "good" use of __proto__, e.g. predefine an object literal's [[Prototype]] to null.

If we want to defer strict mode adoption until <| is added, we'll have less time gaining feedback on the migration costs of ES5 strict mode. This could be worth that cost if "use strict"; is too hard to test both ways, compared to a true

  use strict;


  use version 6;

pragma that downrev browsers will fail to parse rather than silently ignore. But do we really want to add another reason for developers to avoid ES5 strict mode?

Separately from that, implementors won't want to evolve the meaning of ES5 strict much. Continuing to add restrictions to it, especially runtime semantic shifts instead of early errors, as in what's proposed below, smells very bad to me. Progressively more restrictive implementations risk developer blow-back for the hard-to-find bugs introduced by such shifts.


----- Original Message -----
From: "Mark S. Miller" <erights at google.com>
To: "David Bruant" <bruant.d at gmail.com>
Cc: "Douglas Crockford" <douglas at crockford.com>, "es-discuss" <es-discuss at mozilla.org>
Sent: Thursday, December 29, 2011 3:00:34 PM
Subject: Re: Why we need to clean up __proto__

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. 


es-discuss mailing list
es-discuss at mozilla.org

More information about the es-discuss mailing list