Question

Someone mentioned that immediate or self-executing functions have to store the whole stack. Is this true…If so what are the pros and cons of using something like the module pattern (which is based on an immediate function) vs. a plain function?

A function is inherently private, but you can return items that you want to be public, so it can handle privacy.

The main difference I see, is that you don’t have global imports or the ability to make sure that the developer ( wait that’s me ) uses new with the function ( or it is complicated ).

In general when trying to provide privacy and state when should one use the module pattern and when should one just use a plain function?

A second side question is does a function provide state when used with new?

Answer 1

Any function closure that persists because there are lasting references to variables or functions inside it occupies some amount of memory. In today’s computers (even phones), this amount of memory is generally insignificant unless you’re somehow repeating it thousands of times. So, using the language features to solve your design problems is generally more important than worrying about this amount of memory.

When you say “the whole stack”, the calling stack for a top-level self-executing function is very small. There’s really nothing else on the stack except for the one function that’s being called.

A function is also an object. So, when it’s used with new, it creates a new object that can have state (it’s properties) if you assign values to those properties. That’s one of the main ways that objects are created in javascript. You can either call a function and examine it’s return value or you can use it with new and the function serves as the constructor for a new object. A given function is usually designed to be used in one way or the other, not both.

The module pattern is generally used to control which variables are public and when making them public to put them into a structured namespace that uses very few top-level global variables. It isn’t really something you choose instead of self-executing functions because they don’t really solve the same problem. You can read more about the module pattern here: http://www.yuiblog.com/blog/2007/06/12/module-pattern/

You can read about a number of the options here: http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth and http://www.klauskomenda.com/code/javascript-programming-patterns/.

It is easier to discuss the pros/cons of a given technique in light of a specific problem that one is trying to solve or a specific design issue rather than a generic discussion of which is better when the things you’ve asked about are not really solving equivalent issues.

The best reference I know of for protected and private members (which can be hacked into javascript, but are not a core language feature) is this one: http://javascript.crockford.com/private.html. You are making tradeoffs when you use this method instead of the default prototype feature of the language, but you can achieve privacy if you really need it. But, you should know that javascript was not build with private or protected methods in mind so to get that level of privacy, you’re using some conventions about how you write your code to get that.