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
