Transitioning to strict mode

[Mark S. Miller]

I think I would have preferred that. But thinking back to the constraints
we imposed on ourselves during the ES5 design process, I doubt we could
have made that choice. Every additional difference between ES3 (or ES5
sloppy) vs ES5 strict had to be argued for. The counter-argument was
"migration tax". Given how slow the uptake of strict mode has been, the
migration tax counter-argument was even more right than I thought at the
time.


On Thu, Feb 21, 2013 at 12:37 PM, Claus Reinke <claus.reinke at talk21.com>wrote:

> For the ES5 semantics of the interaction of the global scope and the global
>> object, how could you make this a static error? What would you statically
>> test? Would you statically reject the following program, where
>> <someExpression> is itself just some valid expression computing a value
>> (that might be the string "foo")? Note that "this" below is the global
>> object, since it occurs at top level in a program.
>>
>> "use strict";
>> this[<someExpression>] = 8;
>> console.log(foo);
>>
>
> My first reaction would be to reject the 3rd line statically. We can't
> hope to check dynamic scoping statically, but we could enforce
> safety of the language parts that look like they invoke static scoping.
>
> Either declaring 'foo' or logging 'this["foo"]' would be available as
> workarounds. So I don't see this example as an argument for a
> runtime error on the 3rd line.
>
> Claus
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130221/0c03d846/attachment.html>