Using closures in the constructor function to create "private" methods and member variables is an interesting technique that I hadn't considered. As noted in the Crockford article, closures are not especially well documented or well understood, which can lead to confusing or buggy code. Closures can also cause memory leaks if not used properly (see http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp). Nonetheless, it is a potentially powerful and useful option if used properly.
Using closures for information hiding in a JavaScript object that uses only JavaScript native objects doesn't pose a memory leak risk. Memory leaks are not inherent in using closures.
The IE memory leaks have three pre-conditions:
1.) IE,
2.) a circular reference (which may be created by a closure),
3.) a host object implemented as a COM object.
It's not closures that are the problem but the way that COM based host objects are garbage collected by IE.
I recently wrote about closures on my blog:
http://jrdodds.blogs.com/blog/2006/05/javascript_clos.html
All true. Which is why I said they "can" cause memory leaks "if not used properly". :-)
I suppose it would have been more accurate to say that they "can cause memory leaks in IE if not used properly". I just didn't want to get into the details in my reply, which is why I included the MSDN reference.
Previous Message
Up
