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;
or
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.
/be
----- Original Message -----
From: "Mark S. Miller" <[email protected]>
To: "David Bruant" <[email protected]>
Cc: "Douglas Crockford" <[email protected]>, "es-discuss"
<[email protected]>
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.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
