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 <[email protected]>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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
