Article:		Object-oriented JavaScript
Subject:		Nice articles, but a major imprecision
Date:		2006-06-08 00:17:16
From:		andrea.campi
I like the comparative approach with C#, as it helps ensure more and more people can appreciate the support JavaScript provides for writing good code. But when the author suggests that "JavaScript does not support any concept of method or property visibility: every property and method is always public", well... he's completely wrong. Sure, it may not have some nice built-in way to do that (although you could argue prototype isn't nice either), but there is plenty of experience in data hiding in JavaScript, both at instance and class level (static variables and functions). For reference, you can have a look at http://www.crockford.com/javascript/private.html, but there is much more around. You may also want to look at a post on my blog where I compare several different approaches, and I also provide links to more people who have solved this problem: http://www.webcom.it/blog/articles/2006/05/24/private-static-members-in-javascript Andrea

Previous Message

Next Message

• Nice articles, but a major imprecision
  2006-06-08 06:47:49 Greg.Brown
  
  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.

  
  Greg
  
  
  

  • Nice articles, but a major imprecision
    2006-06-08 07:23:35 jdodds
    
    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
    
    

    • Nice articles, but a major imprecision
      2006-06-08 07:40:35 Greg.Brown
      
      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.

      
      Greg