assignment to eval in strict code
Allen.Wirfs-Brock at microsoft.com
Fri Feb 13 09:52:17 PST 2009
The easiest place to ban it would be in PutValue as References now carry sufficient state to identify them as simple identifier bindings in strict mode.
From: Mark Miller [mailto:erights at gmail.com]
Sent: Thursday, February 12, 2009 5:24 PM
To: Waldemar Horwat
Cc: Allen Wirfs-Brock; es-discuss
Subject: Re: assignment to eval in strict code
On Thu, Feb 12, 2009 at 5:17 PM, Waldemar Horwat <waldemar at google.com<mailto:waldemar at google.com>> wrote:
Allen Wirfs-Brock wrote:
Now that we have decided that all declarations of the identifier "eval" are banned from strict code a related question has come up from one of the implementers of our strict mode prototype implementation. Why does Es3.1 still allow assignment to the identifier "eval" within strict code? That does seem like a logical extension of the arguments that convinced us to ban strict mode eval declaration. Does anyone have a reason why such an assignment would be a reasonable thing.
Adding that assignment restriction is a bit of a feature creep but something that is probably manageable in the time we have left if the consensus is that it makes sense to do.
How would you ban it? Would you make every property and variable read-only if its name happens to be "eval"?
Ban it by a purely syntactic rule affecting only variables, not properties.
eval = 8;
var eval = 8;
would be statically rejected in strict code, but
x.eval = 8;
would be fine, even if x turns out to be the global object. Of course, if other code in that frame has already frozen the 'eval' property of the global object, then the property assignment would fail as well. But this has nothing to do with strict mode, and needs no additional machinery in the ES3.1 spec.
Text by me above is hereby placed in the public domain
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss