4 ms·
var ASM_CONSTS = [(function(){ var err = new Error; print('Stacktrace: \n'); print(err.stack) } // ... The issue is that print call
by ChrisSD 7y ago
var ASM_CONSTS = [(function(){
var err = new Error;
print('Stacktrace: \n');
print(err.stack)
} // ...
The issue is that print call. They expect it to call their own print function. But that's not in scope so it falls back on window.print (I.e. the function defined in the global object).
- ncr100 7y agoCode coverage auditing, Test error handling.
- Sharlin 7y agoUse of a language with sane scoping rules…
- Cthulhu_ 7y agoYeah I wouldn't mind a run mode or utility where you don't have the window global and you have to explicitly import what are currently globals. It should be doable with e.g. a webpack or browser plugin.
- acdha 7y agoI’d categorize this not as scoping but the polluted global namespace in the browser environment and JavaScript’s behavior of ignoring extra arguments.
- Sharlin 7y agoIt’s not a global `print` function that’s called but `window.print`, right? `print` is sugar for `this.print` and `this` is the window object if it’s not explicitly bound to something else. So I’d definitely say it’s a very JS-specific scoping issue.
- laszlokorte 7y agoIt‘s not that print is sugar for this.print but that print is undefined and undefined variables fall back to a lookup in the global window object.
- acdha 7y ago> It’s not a global `print` function that’s called but `window.print`, right? `print` is sugar for `this.print` and `this` is the window object if it’s not explicitly bound to something else. This is a common point of confusion because in a browser the global object is traditionally the same as window (or “self” or “frames”) so there wasn't a difference for many years until ES5 introduced strict mode, which left the default as undefined instead of silently using the global object, and things further fractured with Node (where it's “global”) and Web Workers (where only “self” works). (In browsers this is also complicated by the Window/WindowProxy distinction — see https://blog.whatwg.org/windowproxy-window-and-location https://blog.whatwg.org/windowproxy-window-and-location and especially https://mathiasbynens.be/notes/globalthis#terminology https://mathiasbynens.be/notes/globalthis#terminology) A couple years back, “globalThis” was added to make it easier to write portable code across different environments without having to check various names: https://github.com/tc39/proposal-global https://github.com/tc39/proposal-global I don't think is not a particularly JavaScript-specific issue because any language which inherits scope can have the problem of a symbol not matching what you expected, which is why the ones which don't have compile-time checking tend to use linters which will report use of things which haven't been explicitly declared (not mention shadowing built-in names). If you want to blame JavaScript, the feature which would have made this more obvious would have been not ignoring extra arguments – print("foo") triggering an error at that point in the source would make it more obvious.
- Sharlin 7y agoWow, that’s pretty horrible.
- minitech 7y ago> It’s not a global `print` function that’s called but `window.print`, right? Both are true. Globals are stored on `window`. > `print` is sugar for `this.print` It is not.
- quickthrower2 7y agoJust don't call the method "print"
- Sharlin 7y agoHope that was irony.
- ky3 7y agoBut this doesn't completely explain why the error's thrown? After all, Math.round was called on a perfectly innocuous 11.1 and not some crazy NaN.