Jup das ist leider der einzige (möglichst simple) Weg. Andere möglichkeit wäre den Timeout auszulagern und den i zu übergeben. Aber ist halt leider so :/
Unser Bruder
Use `let` not `var`. I your brother worked hard to help get this into ES6, where it means that each iteration has its own binding environment, so the closure works as you want it to. Guten Abend!
I didn’t realize that. So JavaScript declaration-site distinctions between let and var are the analog of C++ lambda-site distractions between capture by variable or by value.
Of languages supporting mutability, only Haskell IORef t and ML t ref are voodoo-free in this tegard. There, identifiers are always bound to constants, and references must be explicitly read and written.
This highlights that in an imperative language, the default loop form should be something like “for(i in 1 to 10) ...” with the semantic that each iteration has a distinct x binding, and no need to explain away why the i’s before and after the i++ are different i’s.
No, this isn't about that. Do you mean JS has both reference (object) and primitive (null undefined boolean number string) types? Thank Java for that one :-/. "Make it look like Java!"
I don't think that's what I meant (boxed vs unboxed types). See this example for what I'm thinking https://ideone.com/FH8Nzp
Basically when the closure is created, is the variable "shared" with other closures, or does it get a unique copy? Seems like you get the sharing with var
You cannot reference the env as an object in JS, so your example does not demonstrate the difference you describe. Instead, there is only one var binding and (in the spec and common implementations) only one env for it. Looks like global scope without an IIFE around top level.
So whether an implementation captures envs or bindings (which are mutable of course, unless const), there is no way to distinguish in JS. Neither is required by the spec. I looked at Chez Scheme optimizations in SpiderMonkey long ago.