indirect eval spec too severe?
erights at gmail.com
Sat Jan 24 16:51:26 PST 2009
On Sat, Jan 24, 2009 at 3:36 PM, David-Sarah Hopwood
<david.hopwood at industrial-designers.co.uk> wrote:
> Mark S. Miller wrote:
>> As for restrictions on assignment to "eval", so long as the global "eval"
>> might be assigned by nonstrict code, it doesn't help much to prevent it's
>> assignment by strict code.
> If the spec were changed to require that the global 'eval' property is
> initially mutable, then that would imply that an implementation that
> makes it initially immutable (using a setter that throws EvalError) would
> not be conformant to ES3.1.
> I see no reason why such an implementation should be considered
> nonconformant. Do we really want any code to be mutating the global
> 'eval' property? Do we have any evidence that real-world code is doing
> so? If not, then why change the spec to require it to work?
The current spec language allows the global eval property to be, in
effect, either mutable or not, benefiting no one. If we need to allow
correct programs to be able to mutate it (in an initial environment in
which it has not yet been frozen), then we should change the spec to
require it to be initially mutable, so that correct programs can rely
on this. If you are correct that we do not need to allow this
possibility, then we should change the spec to require it to be
initially immutable, so that correct programs can rely on that
instead. However, in that latter case, a failed assignment should
result in the normal behavior of a failed assignment, rather than
throwing an EvalError.
Text by me above is hereby placed in the public domain
More information about the Es-discuss