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
On Thu, Feb 21, 2013 at 9:12 AM, David Bruant bruan...@gmail.com 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
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
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();
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
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
6 matches
Mail list logo
