2 ms·
If you want to understand what I’m saying, then consider carefully if your solution even fixes the leak. It doesn’t. The original post isn’t clear on this and m
by pizlonator 2y ago
If you want to understand what I’m saying, then consider carefully if your solution even fixes the leak. It doesn’t. The original post isn’t clear on this and maybe that’s what you’re confused about.
You’re right that the spec doesn’t call for a particular closure representation, but it makes only one representation practical due to the shared mutable state of scopes, which is mandated by the spec. This makes JS’s closures unlike closures in other languages, which allow for greater flexibility. But thats off topic for the original post - the leak - since that leak would exist even with your proposed separate scopes.
Again: stated most precisely, and as I’ve said more than once in the thread, the leak is that closure #2 closes over closure #1, not that closure #2 closes over a separate variable in the same scope. Making the scopes separate won’t fix the leak.
- Zacru 2y ago>closure #2 closes over closure #1 I don't see this in the example. Closure #1 is never bound in the scope, as far as I can tell. Could you explain how closure #1 is closed over without being bound?