Re: Transitioning to strict mode
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 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 >> 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[] = 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Transitioning to strict mode
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 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[] = 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Transitioning to strict mode
You still need more than statement or branch coverage. Otherwise,
we might get 100% "coverage" while missing edge cases
function raise() {
"use strict";
if( Math.random()>0.5 || (Math.random()<0.5) && (variable = 0))
console.log(true);
else
console.log(false);
}
raise();
raise();
raise(); // adjust probabilities and call numbers until we get
// "reliable" 100% branch coverage with no errors; then
// wait for the odd assignment to happen anyway, in
// production, not reproducably
There is no "reliable 100% coverage" in this case. The coverage I guess is...
probabilistic?
Yes, and yet current test coverage tools, even if they go beyond
statement coverage and test for branch coverage, will happily
give you a 100% coverage report (with a little tuning, even
repeatedly). That is why the page you linked to talks about levels
of test coverage beyond branch coverage, and why it is important
to know about such limitations.
Given the complexities of test suites and experience with irreproducible
bugs, testers might even be tempted to overlook the occasional random
test suite failure if it doesn't happen again on re-running the suite?
I understand errors can be caught by a try-catch placed for other reasons, but whoever cares about
transitioning to strict mode will be careful to this kind of issues.
I was thinking of services that need to stay up, no matter what
(restart first, check what happened later). At least, one can hope
that they would notice a Reference error in their logs.
Other fixes for all the error cases are welcome as contributions.
Providing fixes is good. It would be even better if there was a tool
that pointed out any and all potential problem spots related to strict
mode introduction, flagging non-strict-safe functions for review
(Ariya's validator does only check syntax, not scoping or this, I think,
but might serve as a starting point).
But now we're into debugging strict-mode-related issues, instead
of using strict mode to reduce the likelihood of issues.
I used to be firmly in the (naïve?) strict-mode-is-better camp and
couldn't understand why switching everything to strict mode was
considered a bad idea. This thread has documented the reasons
why some coders are wary about the idea. If your page can help
to steer a way around the obstacles, even better.
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
Tom Van Cutsem wrote: That said, I don't think this is enough evidence either for or against the breaking change. I have a hard time believing we can break ES5. It has been shipping for years (plural, at least in one case) in major browsers that evergreen their user bases. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Transitioning to strict mode
On Thu, Feb 21, 2013 at 9:12 AM, David Bruant wrote: > Le 18/02/2013 23:29, Claus Reinke a écrit : > > What I'd like to understand is why likely static scoping problems >> should lead to a runtime error, forcing the dependence on testing. >> If they'd lead to compile time errors (for strict code), there'd be no >> chance of missing them on the developer engine, independent of incomplete >> test suite or ancient customer engines. Wouldn't that remove one of the >> concerns against using strict mode? What am I missing? >> > I guess it's too late now for ES5 strict mode. > What was the rationale behind making it a runtime error? > > I think there were plans to make it a compile-time error... was it with > the ES6 opt-in? :-s > Can it be retrofit in new syntax which are their own opt-in (module, > class...)? 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 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[] = 8; console.log(foo); -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Transitioning to strict mode
Le 18/02/2013 23:29, Claus Reinke a écrit :
Out of curiosity, what does your favorite test coverage tool report
for the source below? And what does it report when you comment
out the directive?
:-p Ok, there are exceptions if your code depends on semantic changes
described in the third section of the article (dynamic
this/eval/arguments).
That's you case with how you define isStrict (dynamic this)
So: if your code does *not* depend on semantic changes, all instances
of setting to an undeclared variable will be caught.
Just wanted to shake your faith in testing :-) The example code might
look unlikely, but real code is more complex and might evolve nasty
behavior without such artificial tuning.
You still need more than statement or branch coverage. Otherwise,
we might get 100% "coverage" while missing edge cases
function raise() {
"use strict";
if( Math.random()>0.5 || (Math.random()<0.5) && (variable = 0))
console.log(true);
else
console.log(false);
}
raise();
raise();
raise(); // adjust probabilities and call numbers until we get
// "reliable" 100% branch coverage with no errors; then
// wait for the odd assignment to happen anyway, in
// production, not reproducably
There is no "reliable 100% coverage" in this case. The coverage I guess
is... probabilistic?
Throwing or not throwing Reference Errors is also a semantics change,
and since errors can be caught, we can react to their presence/absence,
giving another avenue for accidental semantics changes.
I agree it's a semantic change, but it's one that's special in the
development workflow. The common practice is to fix code that throws,
whatever that means.
non-directly-throwing semantic changes require a different kind of
attention and testing.
I understand errors can be caught by a try-catch placed for other
reasons, but whoever cares about transitioning to strict mode will be
careful to this kind of issues.
Undeclared variables are likely to be unintended, and likely to lead to
bugs, but they might also still let the code run successfully to
completion where strict mode errors do or don't, depending on
circumstances.
I agree. The goal when transitioning to strict mode is also to preserve
the semantics of the original code. I've tried to provide examples of
how to fix common errors. For the undeclared variable case, I've
explained how to legitimately assign a global variable if that's what
was really intended. This way, there is a quick fix that preserves the
semantics.
Other fixes for all the error cases are welcome as contributions.
Testing increases confidence (sometimes too much so) but cannot
prove correctness, only the absence of selected errors.
I fully agree.
What I'd like to understand is why likely static scoping problems
should lead to a runtime error, forcing the dependence on testing.
If they'd lead to compile time errors (for strict code), there'd be no
chance of missing them on the developer engine, independent of
incomplete test suite or ancient customer engines. Wouldn't that
remove one of the concerns against using strict mode? What am I missing?
I guess it's too late now for ES5 strict mode.
What was the rationale behind making it a runtime error?
I think there were plans to make it a compile-time error... was it with
the ES6 opt-in? :-s
Can it be retrofit in new syntax which are their own opt-in (module,
class...)?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
