4 ms·
It looks like you opened the article, hit "ctrl+f closure", saw 0, and went on a rant. In the examples where the turned an anonymous function into a named func
by zemo 13y ago
It looks like you opened the article, hit "ctrl+f closure", saw 0, and went on a rant. In the examples where the turned an anonymous function into a named function, the named functions still close over symbols from their calling context, so... it's hard to see what you're on about.
- jameshart 13y agoHis examples only close over parameter variables and lifted functions, not local variables that actually, you know, vary. The fact is, in JavaScript, lifted functions can close over local variables but the fact that they do is not obvious - in fact it's so counterintuitive that you're generally best to avoid doing so. In the first example he gives, two functions that, in the original, are nested, in the refactoring are placed in the same scope, rather than nested within one another. His amended solution prevents the second function from closing over the scope of the first, which is possible in the original, or an async form. If you wanted to share state from the first function to the second, you'd have to realize you could bring the second function into the scope of the first, and then move it, and then you're back where you started with nested callbacks. But amending this code is made harder than it should be by the decision to factor the two closures out to the widest possible scope, rather than the narrowest. And the fact that ctrl-F closure yields no results just confirms the feeling that the examples gave me that the author is playing around with closures without knowing what he's actually doing.