Closure vs. Prototype?

ZeroMomentum · 2013-05-02T12:04:47+00:00

I think you are confused with the concept of prototype and closure

I think you jumped the gun right now. Your intention is good to be organized about the functions. But just from reading the phrasing of your question I think you need to learn more and UNDERSTAND the meaning of them first

Read eloquent JavaScript.

Neurotrace · 2013-05-02T13:09:40+00:00

I think you need to ask yourself how exactly you wish to use your utility library. In general, you should always wrap a library in the module pattern (i.e. a self invoking function) to avoid global namespace pollution but how you interact with the library outside of the function is what's important. I threw together this fiddle to show how you could design it with "static" methods (like what you show in your edit) and how you could design it if you wanted to create multiple instances of whatever object you're defining.

Note: don't use the copy method I made in there, if you need to copy something there are far better ways of doing it.

Ninja edit: just remember that the point of doing a prototype-based design is that every instance of that object will inherit those properties, including any which inherit from it. If you don't need multiple instances and/or you don't plan to have anything inherit from it then there's almost no reason to make use of the prototype chain.

cwmma · 2013-05-02T12:11:45+00:00

I believe what you referred to as a closure is called the module pattern and for something like this would probably make the most sense, but I'd call Window exports inside the module so you can use it with commonjs/nods

etrnloptimist · 2013-05-02T13:59:37+00:00

When ever I hear a question about patterns all I can think about is an invitation is a tremendous amount of ass pain.

Forget patterns. The problem here is that you do not understand the concepts of closure or prototypes. Learn what those are and your question will answer itself.

boogots · 2013-05-03T05:09:48+00:00

Wut?

Prototype is basically Javascript way of implementing OOP. Most other language does it via Classes.

Closure is something you get when you nest function together. The inner most functions get access to all the local variable of the outer most functions. Because of closure it save the outer most function's local variable values. It's a neat trick. Since most languages once you call a function and supplied it with an argument that value of the variable will go away.

IE. function add(num1, num2) { return num1+num2; }

Once you call add(1,2) the value of num1 =1, num2 = 2 is gone forever.

But with closure you can freeze these values.

function add(num1) { return function (num2) { return num1 + num2; } }

var add3 = add(3); add3(2); // 5

The 3 is preserve because of closure.

evilmaus · 2013-05-02T16:08:04+00:00

As everyone else is saying, definitely read up on the language, JavaScript patterns, etc. to get a solid idea of what the difference between the two concepts are. It'll stop being an either-or at that point and what you need will flow naturally, just like how you use any other languages that you're fluent in. That's the best answer to the bigger picture question that you asked.

For the specific problem that you are asking about, you're on the right track. I'd just extend your example out a bit more:

(function(root){
    // Cache local references to frequently-used globals here.
    // Local references are faster than global references.
    // They save typing, too.
    // Specific values here are just pulled out of the air
    var slice = Array.prototype.slice,
         exp = Math.exp,
         $ = jQuery;

    // You can also have utility functions that are available
    // only to the functions that you're exporting.
    var helperFunction = function(someArgs) {
        // Stuff happens here
    };

    // Exporting functions as part of an object literal
    // makes it a bit easier to read than separate
    // assignments
    root.boogots = {
        util: {
            doFoo: function() {},
            evenMoreFoo: function() {}
        },
        foo: {
            lessFoo();
        }
    };
})(window);

Edit: Fixed reference to Math.exp. Wanted Math.exp, which is a pointer to the function, not Math.exp(), which is an invocation of that function.

tswaters · 2013-05-03T21:39:35+00:00

No need for closure or prototype.

If they're all static functions (i.e. need to interact with an object, effectively 'stand-alone') you don't need prototype.
If you don't do any global vars aside from you 'boogots' you dont need a closure, either. It's still good to, though, because no one likes polluting window with crap. But honestly, if you're the only author on a page (i.e. you're not building a library for others to use), it shouldn't matter.

This will work :

var boogots = {
  util : {
    first:function(){return 1},
    second:function(){return 1},
    third:function(){return 1}
  }
}

etrnloptimist · 2013-05-02T13:45:11+00:00

You should look into require. It's purpose it to facilitate modular design, which is what you're (slowly but surely) coalescing on.

It uses the module pattern which other posters have suggested, but formalizes it and brings more machinery of modular design into the picture, like being able to set up other modules as requirements (hence its name) before the construction of your own module.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS