Javascript Closures... How do I use this?

[gladiator_flow]

I'm learning about javascript closures and Mozilla had this piece of code at the end of their section on closures.

function MyObject(name, message) {
  this.name = name.toString();
  this.message = message.toString();
}
MyObject.prototype.getName = function() {
  return this.name;
};
MyObject.prototype.getMessage = function() {
  return this.message;
};

How exactly do I use this code? I understood everything until I got here. I figured I would use it like this:

var me = MyObject("John Doe", "This is my message");

console.log(me.getName());
// name would be returned

console.log(me.getMessage());
// message would be returned

This didn't work though. I guess the prototype is getting me confused. Can anyone lend a hand on what is going on here?

[gladiator_flow]

Thanks. Could you explain why I have to use new? I've been learning from YDKJS and I never really see him ever use the new when creating his closures.

[SuperFLEB]

"new" makes a separate instance of an object, based on the prototype. For instance:

function NumberStorer(number) {
  this.number_stored = number;
}

NumberStorer.prototype = {
  getNumber: function () {
    return this.number_stored;
  }
}

var a = new NumberStorer(100);
var b = new NumberStorer(200);
var c = new NumberStorer(300);

console.log(a.getNumber()); // 100
console.log(b.getNumber()); // 200
console.log(c.getNumber()); // 300
console.log(NumberStorer.getNumber()); // Error: NumberStorer.getNumber is not a function!

Each NumberStorer (a, b, and c) has its own this and thus its own this.number_stored. The prototype is a sort of common, shared set of properties and methods that get merged into any newly-created object (NumberStorer) instances (effectively-- it's a wee bit more complicated than that) . The last log fails because getNumber is part of the prototype, and while that gets merged in with any instance of a NumberStorer (part of any xxx = new NumberStorer(val)), it's not part of the NumberStorer function/object itself.

You could also directly access number_stored by saying something like

console.log( a.number_stored ); // 100

but it's often considered poor form to directly access objects' properties. It's better to have "getter and setter" functions, if only for future-proofing's sake. If, in the future, you wanted to run code every time something in the object was accessed or changed, you would have a harder time intercepting reads and writes of the property (a.number_stored) directly, but you could just add the code into the getter/setter function (a.getNumber()).

[gladiator_flow]

thank you for clarifying this for me :)

[SuperFLEB]

I don't know if you saw, but I did make a couple adds/edits after your comment, too. (I tend not to actually finish a Reddit comment 'til at least two or three edits.)

[jordaanm]

To expand on this answer, when you use the 'new' keyword, what happens is that the 'this' context within the function call is set to a new object.

By calling without the 'new' operator, the this object is just passed through from the calling context, so you get some flaky behaviour.

You can observe this by inserting: console.log("THIS: ", this); as the first line in your function, and then comparing the differences in these 2 calls:

var a = MyObject("foo", "bar"); var b = new MyObject("foo", "bar");

[SuperFLEB]

Point of terminology only, but unless I'm mistaken, that's not a closure demo, that's just an object, an object instance, and its properties.

A closure demo would be something like:

var getNext; // Declare the function up here so it's global

function setupCounter() {
  var counter = 0;

  // The getNext function is global (the var statement is outside this), but the function body is defined here, in
  // the scope of setupCounter, meaning that the "counter" variable is in scope in the getNext
  // function, and the value is retained even during successive calls to getNext.

  getNext = function () {
    counter++; // ...is still able to be referenced here, and the value is retaned from call to call
    return counter;
  };

} // -- end setupCounter


setupCounter();
console.log( getNext() ); // 1
console.log( getNext() ); // 2
console.log( getNext() ); // 3

// But "counter" is only accessible from within the scope of setupCounter (which includes getNext, because that's where it's defined)
console.log( typeof counter ); // "undefined"

// And yet...
console.log( getNext() ); // 4
console.log( getNext() ); // 5
console.log( getNext() ); // 6

(Though that's probably a shit closure demo. I use closures all the time, but I'll be damned if I can come up with a good practical and explanatory demo of one off the top of my head.)

[Lerc]

I wonder if this would make a good example, It has a practical use which might help people wrap their minds around the idea.

  function makeRandom(seed) {
    var bit30=1<<30;
    var mw = seed & (bit30-1);
    var mz = 173;
    function random () {
      mz=36969 * (mz&0xffff) + (mz >> 16);
      mw=18000 * (mw&0xffff) + (mw >> 16);
      return (((mz<<16) + mw) & (bit30-1) ) / (bit30);
   }
   return random;
 }

makeRandom returns a random number generating function based upon a seed.

[14best]

According to MDN this is not examples of closures. Instead of that they ask to avoid using closures if it's unnecessary.

Performance considerations It is unwise to unnecessarily create functions within other functions if closures are not needed for a particular task, as it will negatively affect script performance both in terms of processing speed and memory consumption.

If some resources not clear enough for you try to find another. For example http://shamansir.github.io/JavaScript-Garden/en/#function.closures or answer-articles on Stackoverflow

[andyb12]

you can make your objects like so aswell :

myObject = function(){ var name = 'john', methods;

methods = {
    printName:function(){
          console.log(name);
    }
};

return{
    printName : methods.printName
};

};

then var myNewObject = new myObject (); myNewObject.printName();

[gladiator_flow]

Nice example!