A surprising JavaScript memory leak found at Meteor

Re:A surprising JavaScript memory leak found at Meteor by jcampbell1 on Friday June 28, 2013 @02:35PM (#5959617)

> In the logical sense each function has its own closure. There is no way functions should affect the variables closed on by each other. So you shouldn't expect this.

What? The whole point of a closure is that it is shared.

[ Parent | on HN ]

Re:A surprising JavaScript memory leak found at Meteor by Dylan16807 on Friday June 28, 2013 @02:49PM (#5959683)

The point of closures is to share variables, but each closure can participate in different shares.

[ Parent | on HN ]

Re:A surprising JavaScript memory leak found at Meteor by bmm6o on Friday June 28, 2013 @03:25PM (#5959873)

Part of the reason people are misunderstanding you is that terminology got abused a little bit upthread.

"I just always assumed that all the variables present in a closure are maintained" should really be (something like) "I just always assumed that all the variables present in a scope that produced a closure are maintained". You're right that a closure only needs to contain the variables that are closed over, and that some of those variables are scoped such that they can appear in multiple closures.

[ Parent | on HN ]

Re:A surprising JavaScript memory leak found at Meteor by DanWaterworth on Friday June 28, 2013 @03:43PM (#5959960)

> You're right that a closure only needs to contain the variables that are closed over.

You would think so, but this assumption fails in the presence of eval.

[ Parent | on HN ]

Re:A surprising JavaScript memory leak found at Meteor by bmm6o on Friday June 28, 2013 @03:55PM (#5960025)

Sure, but that's the only exception, right? If there's no eval call in the function that requires the closure it's easily determined what variables don't need to be included, right?

[ Parent | on HN ]