[This is an excerpt from the book, Microsoft AJAX Library Essentials: Client-side ASP.NET AJAX 1.0 Explained, by Cristian Darie, Bogdan Brinzarea. Published by Packt Publishing Ltd., 2007]
The Table "class" from the previous example contains a "method" named
getCellCount(). The following code creates the same class, but this time adding
getCellCount() to its prototype:
Each execution context has an associated scope, which specifies the objects that are accessible to the code executing within that context.
The scope of the global execution context contains the locally defined variables and functions, and the browser's
window object. In that context,
this is equivalent to
window, so you can access, for example, the
location property of that object using either
The scope of a function execution context contains the function's parameters, the locally defined variables and functions, and the variables and functions in the scope of the calling code. This explains why the
getCellCount() function has access to the
_columns variables that are defined in the outer function (
The scope of the
eval() execution context is identical to the scope of the calling code context. The
getCellCount() function from the above code snippet could be written like this, without losing its functionality:
var x, this.x, and x
An execution context contains a collection of (key, value) associations representing the local variables and functions, a prototype whose members can be accessed through the this keyword, a collection of function parameters (if the context was created for a function call), and information about the context of the calling code.
Members accessed through this, and those declared using var, are stored in separate places, except in the case of the global execution context where variables and properties are the same thing. In objects, variables declared through var are not accessible through function instances, which makes them perfect for implementing private "class" members, as you could see in an earlier exercise. On the other hand, members accessed through this are accessible through function instances, so we can use them to implement public members.
When a member is read using its literal name, its value is first searched for in the list of local variables. If it's not found there, it'll be searched for in the prototype. To understand the implications, see the following function, which defines a local variable x, and a property named x. If you execute the function, you'll see that the value of x is read from the local variable, even though you also have a property with the same name:
Calling this function, either directly or by creating an instance of it, will display 1 and 2—demonstrating that variables and properties are stored separately. Should you execute the same code in the global context (without a function), for which variables and properties are the same, you'd get the same value displayed twice.
When reading a member using its name literally (without
this), if there's no local variable with that name, the value from the prototype (property) will be read instead, as this example demonstrates:
Using the Right Context
Things get a little more complicated when using the this keyword. As you know, each function call creates a new context in which the code executes. When the context is created, the value of
this is also decided:
The second point is particularly important. Using
this in a function that is meant to be called directly, rather than instantiated as an object, is a bad programming practice, because you end up altering the global object. Take this example that demonstrates how you can overwrite a global variable from within a function:
Modifying the global object can be used to implement various coding architectures or features, but abusing of this technique can be dangerous. On the other hand, if
BigTest is instantiated using the
new keyword, the
this keyword will refer to the
new object, rather than the global object. Modifying the previous example as highlighted below, we can see the
x variable of the global context remains untouched:
When creating your own code framework, you can enforce that a function's code is executed through a function instance. The little trick involves creating a new object on the spot if the function was called directly, and using that object for further processing. This allows you to ensure that a function call will not modify any members of the global context. It works like this:
The highlighted line simply checks if the this keyword refers to an instance of
instanceof keyword is used for this). If it's not, a new
BigTest instance is returned, and execution stops. The
BigTest instance, however, is executed, and this time this will be a
BigTest instance, so the function will continue executing in the context of that object.