Thought this one might come in handy for some of us closure noobs: http://blog.morrisjohns.com/javascript_closures_for_dummies
On Mon, Feb 25, 2008 at 1:58 PM, T.J. Crowder <[EMAIL PROTECTED]> wrote: > > Just reporting back, as I suspected, you won't avoid preserving the > outer function's context by creating an anonymous closure to create > the closure, the entire scope chain is preserved until the request > completes and the reference to the request is released (which allows > the references to the closures to be released, which releases the > scope chain of call objects -- "activation objects" in ECMA parlance > -- since the only remaining references are circular). Sorry for > giving the wrong impression earlier, even if it did come with a > caveat. :) > > But in any case, since the XHR call *will* complete (successfully or > otherwise), and the request will be released, this isn't a memory > leak. It uses memory for a little while (for a good purpose), but > doesn't leak it. > -- > T.J. Crowder > tj / crowder software / com > > On Feb 24, 11:25 am, "Manu Temmerman-Uyttenbroeck" > <[EMAIL PROTECTED]> wrote: > > Thx a lot for helping me visualize it! > > > > On Sun, Feb 24, 2008 at 11:08 AM, Andrew Dupont <[EMAIL PROTECTED] > > > > wrote: > > > > > > > > > On Feb 24, 1:31 am, "Manu Temmerman-Uyttenbroeck" > > > <[EMAIL PROTECTED]> wrote: > > > > The basic example onhttp://prototypejs.org/api/ajax/requestalsohas a > > > > closure, because the onSuccess callback function is defined inline, > > > correct? > > > > So if that 'new Ajax.Request' is in a function, then that url > variable > > > will > > > > not be released until that ajax request successfully finishes and > that > > > > onSuccess function runs? > > > > What happens then when the ajax request is not successfull and > throws an > > > > exception. That url value will stay in memory until you navigate > away > > > from > > > > the page? > > > > > Unless the request object itself gets dereferenced. > > > > > If I'm inside a function and I say... > > > > > var foo = new Ajax.Request(/*...*/); > > > > > ... then once the function goes out of scope, I won't be able to > > > obtain a reference to it again. (This is assuming that variable isn't > > > a part of *some other* closure created inside the function. The > > > browser knows this, so when the request has completed its life-cycle > > > (even by throwing exception), it'll GC the object if nothing > > > references it. And that would also GC the closure formed by attaching > > > that anonymous function to the object. > > > > > Now, if I say... > > > > > window.foo = new Ajax.Request(/*... */); > > > > > ... then I've set a global reference that will never go out of scope. > > > That means my request object won't be GC'ed unless I explicitly > > > dereference later on (window.foo = null). > > > > > Let's make a diagram. Think of "window" (the global scope) as a big > > > circle in the middle of the page. Imagine everything -- strings, > > > numbers, objects, etc. -- as nodes. Now draw lines between nodes to > > > make references. (window connects to Ajax, Ajax connects to > > > Ajax.Request, etc.) > > > > > Anything that can be traced back to "window" must be kept in memory. > > > If I remove a reference to something, that erases a line from the > > > diagram, and any resulting "node island" can be GC'd. Even if you've > > > got two objects that reference one another, if neither one of them can > > > be referenced from the global scope, they can be purged from memory, > > > since it's impossible to refer to them. > > > > > (Of course, IE has its own problem with circular references, which > > > brings me to your next question...) > > > > > > What happens when you didn't only store a url string, but let's say > a > > > > reference to a collection of 200 dom objects and the ajax request > fails. > > > > Circular reference? Meaning a 'real' memory leak. That memory won't > be > > > > released even after navigating away from the page. > > > > > Yeah, and that's the sort of thing that can't easily be solved inside > > > the JS environment (except through cautious coding). Of course, IE7 > > > claims to have fixed many of those leaks, so maybe you should make a > > > test page and find out. ;-) > > > > > Cheers, > > > Andrew > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
