Javascript scoping and closure problem

Please see my comment to the Solution 1. In addition to that, I want to say:

It's really important to clear the mind from OOP ideas. This is what is called "distractions" in this article: JS Objects: Distractions.

I seriously advise to learn and and understand well.

As to your example, I seriously advise you to use strict mode. It will quickly clean up your mind from some of the "distractions". Please see: Strict mode — JavaScript | MDN.

One important thing it does: alert(this) will show undefined. This is very important improvement over the dreaded non-strict execution which would immediately give you the required food for thought.

—SA

I hope you enjoyed the link I provided in Solution 2. Now, let's see what's going on with your simple case. One of the possible solutions would be this:

function Employee() {
  this.name = "Mayank";
  this.Age = 26;
  this.salary = 10000;
  // make alculateBonus a property:
  this.calculateBonus = function() {
    alert(this.name); // "Mayank"
    return (this.salary + 1000);
  }
  this.calculateBonus();
}

Let's assume you are using strict mode in all cases. Non-strict behavior is too confusing to use during development. In your original code, alert would show the window object, which is plain wrong (or, those obsolete wrong decisions!) and hard to recognize what is that. I output this.name only to show some evidence that this is correct "this". (In the style of the sayings by Rabbit from Miln's Winnie-the-Pooh: "'this' can be different!". :-))

Of course, in this particular piece of code, making calculateBonus would be utterly impractical, because this is not what you meant to do; you probably did not want to expose this function to the object users. I'm pretty much sure that you knew the practical solution; only it would be not useful to uncover the "mystery" of "this". So, just in case:

function Employee() {
  this.name = "Mayank";
  this.Age = 26;
  this.salary = 10000;
  calculateBonus = function(owner) { // not a property!
    alert(owner.name);
    return (owner.salary + 1000);
  }
  calculateBonus(this);
}

Now, let's say, you want to use the closure. Great! This is actually much better idea than using properties. I hope the solution would be obvious:

function Employee() {
  this.name = "Mayank";
  this.Age = 26;
  this.salary = 10000;
  var name = this.name;
  var salary = this.salary;
  var calculateBonus = function() { // use closure
    alert(name);
    return (salary + 1000);
  }
  calculateBonus();
}

Let's make another step. Why would we need "calculateBonus" at all. Get rid of it:

function Employee() {
  this.name = "Mayank";
  this.Age = 26;
  this.salary = 10000;
  var name = this.name;
  var salary = this.salary;
  (function() { // use closure
    alert(name);
    return (salary + 1000);
  })();
}

Much better, isn't it? Please see Pluralitas non est ponenda sine necessitate, see also:
Occam's razor — Wikipedia, the free encyclopedia,
Immediately-invoked function expression — Wikipedia, the free encyclopedia.

Another variant combining some of the above:

function Employee() {
  this.name = "Mayank";
  this.Age = 26;
  this.salary = 10000;
  var owner = this;
  (function() { // use closure
    alert(owner.name);
    return (owner.salary + 1000);
  })();
}

---

Now, I want to introduce another exciting feature of strict mode. It can help you by taking out false freedom of using the constructors. Try this:

function ConstructorInFact() {
	this.A = 13;
	return 14;
}

var a = new ConstructorInFact();
var b = ConstructorInFact();

I hope that you can see how this code is silly. If this is used as a constructor (a), return 14 is not used. If it is as not a constructor call (b), "this" is pointless. However, all this will work in non-strict mode. Some say it's nice, but it won't detect the silliness of this code. Switch to the strict mode and, for a first attempt, comment out the last line (b). Still, it will work.

Uncomment the last line. In want line the problem will be detected. Surprise: in the line "this.A =…": "this is undefined". Note that the problem only exists if the last line is there.

Wait a minute! Isn't JavaScript an interpreter? No, it is not a pure interpreter. The script is first lexically analyzed. Another surprise? :-)

—SA

Mayank Gupta asked:

Thanks for the reply sir. Its great to see the workarounds for the code I wrote in order to execute it as expected.

Thanks a lot....

But I would also like to know why the above code is Alerting me with the "Window" Object instead of Employee Object

Please see my comment to that question. I though this is obvious.

I already explained that Window Object is the weird artifact of action of the obsolete and unreasonable behavior of JavaScript non-strict mode. You probably understand that the backward compatibility for JavaScript is very serious. This is the only language supported by all browsers. That's why strict mode was created — see Solution 2 and the link. In strict mode, the object "this" is the "undefined" object. By the way, this is a special unique predefined object of the special type "predefined" (not "object"). In strict mode, "this" also can be the reference to the current window object, but only when it is strictly so, when a function is really a property of this object, but to understand it, we will need to discuss it later.

From this point, let's discuss only the cases when strict mode is used, for strictness. :-)
The keyword "this" is used as an argument of a function used inside the implementation of this function, nothing else. So, you need to understand that "this" is a keyword used to access an actual argument of a function. This is a special function argument passed to the function implicitly, not explicitly, that is, it is never appears in an formal argument list. But this argument may or may not be actually passed. It is passed only in some cases:

• Explicitly via .call:
  Function.prototype.call() — JavaScript (see also how it is done in Solution 1).
• Explicitely via .apply:
  Function.prototype.apply() — JavaScript.
• Explicitely bound and indirectly passed via .bind:
  Function.prototype.bind() — JavaScript.
• When a function is called via new operator. In other words, when it is used as a constructor.
• When a function object is called as a property of some object.

[EDIT]

Last item of the above list should be understood "dynamically". It does not really matter if some function object is used as a property, it only matters if the function is called via this property or not. Compare:

var object = [];
object.property = "some property";
object.someFunctionProperty = function() {
	alert(this.property);
}

// will alert "some property":
object.someFunctionProperty();

// but
var f = object.someFunctionProperty;
// will alert "undefined":
f();   

[END EDIT]

As always with JavaScript, if you use some undefined object name is, say, assignment to some variable, this variable starts to reference undefined. This is exactly what happens if this is not actually passed at all. In your case, the function is a local function object; that is, a stack variable. None of the mechanisms which could pass this applies.

Finally, there is one marginal case of this object: use it on the top-level script. Let's say, you don't have any functions at all in your whole page. What is this? It's easy to try. It will reference current window object, in both strict and non-strict modes. It tells you that the top-level script is actually always a function; the JavaScript runtime passed the current window object as this argument to it.

—SA

Thanks for the reply sir. Its great to see the workarounds for the code I wrote in order to execute it as expected.

Thanks a lot....

But I would also like to know why the above code is Alerting me with the "Window" Object instead of Employee Object.

What i assume is that when "new Employee()" is called, it does following things:

1. Create a separate memory block for it.
2. Assign properties to Object
3. Assign this to object
4. Return this

So the code, "new Employee()" is called from the global scope. While the global scope is executing the specified steps, it encounters a function "calculateBonus". The function is now executed under the global context since the new object is still not created.

So when this function is executed from the global scope, therefore the context of function execution becomes "global" and therefore "alert(this)" gives "window" object.

Please tell me if my assumption is correct or not. Or there is some problem in understanding the scope resolution for this function.

Regards,
Mayank Gupta