To summarize: The less we use the term variable, the less is the confusion.

I am curious, do you think such explanation is correct?

Yes, it’s a good explanation. After all, all of them are just properties of something (either of a VO/AO, or an environment in ES5, or a simple object).

Though, for simplicity a term variable in casual talks (when it’s not required to differentiate some deep details) of course can also be used.

Dmitry.

You wrote:

just create the new property (but not the variable) of the global object. “Not the variable” is not in the sense that it cannot be changed, but “not the variable” in concept of variables in ECMAScript

In my view these variable-property discussions brings the most confusion among the developers.

I would replace them with following:

1. All we need is Data
2. Data is accessed in two ways via Identifiers and via Properties (both of them of Reference Type you are talking about)
3. JavaScript creates an identifier for each variable declaration, function declaration and function formal parameter. The identifiers are stored as properties in Variable Object. The identifiers could not be deleted.
4. JavaScript creates a property for each property declaration. Two ways of doing it:
-> p = 5, no var in front of it
-> var obj = {p: 5}
Properties does not affect the VO (except global properties, because VO === GO in Global Context). Properties could be deleted.

To summarize: The less we use the term variable, the less is the confusion.

I am curious, do you think such explanation is correct?
May be a bit over-simplified considering EcmaScript specification but still…..

//Plamen

Looks like a typo error to me. Shouldn’t it be “impossibility to remove variable”?

Well, variables are also properties of something. This “something” is the variable/activation object. Attribute {DontDelete} relates exactly to a property, it’s the attribute of the property. So, it’s not a typo, since, repeat, a variable is also a property but with (initially) with its special attributes. However, to avoid confusion, yes, fixed it to “variable”; thanks.

Dmitry.

“Variables, in contrast with simple properties, have attribute {DontDelete}, meaning impossibility to remove property via the delete operator:”

Looks like a typo error to me. Shouldn’t it be “impossibility to remove variable”?

-nag

I think catch() must be a type of function.

No, it’s a clause of the try statement, it’s not a function. However, yeah, catch adds a special object, containing its argument (in this case — “foo”) in the front of current scope chain, shadowing a global “foo” Therefore, we can refer it during catch block is running. After it ends, its special object is removed from the scope chain and again the global “foo” is available. You can find this case described in detail in the fours chapter, devoted a scope chain.

I tried eval(), which treats local variables as belonging to global scope.

eval works with the calling context and uses the variable object and the scope chain exactly of the calling context (i.e. the context, from which eval is called). Therefore, if a variable is created within eval, it’s created in the calling context; and if you call eval from the global context, of course it creates a variable in the global context. This case is described in the first chapter.

Notice however, that in the strict mode of ES5, eval executes its code in the sandbox environment and cannot create a variable in the calling context.

IE treats foo as global.

IE’s bug.

Dmitry.

var foo = 10;
try {
throw 20;
} catch (foo) {
alert(foo); // 20
}
// again global
alert(foo); // 10

The scenario elucidated above holds good in firefox.
IE treats foo as global.
Thus the result of final alert(foo); statement is 20.

-nag

I think catch() must be a type of function.
I tried eval(), which treats local variables as belonging to global scope.

Thank you very much for explaining in such a great detail.

-nag

In some languages there is a block-scope variables. Such variables are being removed after the scope of block ends.

For instance, in C:

// global
int foo = 10;

if (true) {
  // local
  int foo = 20;
  printf("%d", foo); // 20
} // block ends, its scope too, including local "foo"

// again global
printf("%d", foo); // 10

In JavaScript (in current version of standard) there is no block-scope local variables; only — function-scope local variables.

That means:

// global
var foo = 10;

if (true) {
  var foo = 20;
  alert(foo); // 20
} // block ends, but "foo" wasn't local

alert(foo); // 20

After careful reading of this chapter, you should know, that all variables are created on entering the context stage. This means, that second var in the JS example above is ignored, because there is already a “foo” var (notice, that if the local var in if-statement block was named e.g. “bar”, it also would created on entering the context). And only then, at code execution stage, there is just an assignment in the if-block to global “foo”.

P.S.: actually, JS has some case of block-scope var, however, it’s not an explicit var, but the argument of the catch-clause:

var foo = 10;

try {
  throw 20;
} catch (foo) {
  alert(foo); // 20
}

// again global
alert(foo); // 10

Dmitry.