ECMA-262-3 in detail. Chapter 4. Scope chain.

[Dmitry A. Soshnikov]

Inform you about the next translation:

"ECMA-262-3 in detail. Chapter 4. Scope chain."

http://dmitrysoshnikov.com/ecmascript/chapter-4-scope-chain/

Dmitry.

 

[Garrett Smith]

Inform you about the next translation:

"ECMA-262-3 in detail. Chapter 4. Scope chain."

http://dmitrysoshnikov.com/ecmascript/chapter-4-scope-chain/

Dmitry.

(variables, function declarations and formal parameters of functions)

A parameter creates a variable. If you are going to differentiate
parameters, use "variable declaration" as the first.

The paragraph:
Also, we know that the variable object is created and filled with
initializing values every time on entering the context, and that its
updating occurs at interpretation of a code

 

[Garrett Smith]

(variables, function declarations and formal parameters of functions)

A parameter creates a variable. If you are going to differentiate
parameters, use "variable declaration" as the first.

The paragraph:
Also, we know that the variable object is created and filled with
initializing values every time on entering the context, and that its
updating occurs at interpretation of a code

Sorry. I apparently hit a kbd shortcut and sent the message prematurely.

As I was saying, the paragraph:

| Also, we know that the variable object is created and filled with
| initializing values every time on entering the context, and that its
| updating occurs at interpretation of a code

is a bit odd, grammatically. What are "initializing values"? I believe
you mean the for a function declaration, it would be that function and
for a variable, it would be `undefined`.

In that case, I would reword it to use standard terminology.

Upon entering an execution context, the variable object is created. For
each parameter variable, a property is created and given the initial
value `undefined`. For each FunctionDeclaration, a property with the
function's Identifier is created and given the value of the function.
For each variable declaration, a property is created and given the value
`undefined`.

I would also mention the specification section number as a supporting
reference to the statements. In this case s 10.1.3 (Variable Instantiation).

 

[Thomas 'PointedEars' Lahn]

(variables, function declarations and formal parameters of functions)

A parameter creates a variable.

No, it does not.

If you are going to differentiate parameters, use "variable declaration"
as the first.

ACK


PointedEars

 

[Thomas 'PointedEars' Lahn]

Sorry. I apparently hit a kbd shortcut and sent the message prematurely.

Probably Ctrl+Return, see the File menu of your Thunderbird's Compose
Message window.

[...]
In that case, I would reword it to use standard terminology.

Upon entering an execution context, the variable object is created. For
each parameter variable, a property is created and given the initial

.... a property _on that object_ ... (or whatever preposition fits better)

value `undefined`. For each FunctionDeclaration, a property with the
function's Identifier is created and given the value of the function.

Not "the value of the function", that is too easily confused with the
return value. The declared function itself is in a sense an object value
(a Function instance), but what is stored in the property is only a
reference to the object.


PointedEars

 

[Asen Bozhilov]

Upon entering an execution context, the variable object is created. For
each parameter variable, a property is created and given the initial
value `undefined`.

It's true only for parameters, for which caller doesn't supply values.
If caller supply value for argument, during Variable Instantiation on
created property of VO with name Identifier will be assign value,
which provided by caller.

| 10.1.3 Variable Instantiation

| For function code: for each formal parameter,
| as defined in the FormalParameterList,
| create a property of the
| variable object whose name is the Identifier and whose
| attributes are determined by the type of code. The values
| of the parameters are supplied by the caller as arguments
| to [[Call]]. If the caller supplies fewer parameter values
| than there are formal parameters, the extra formal
| parameters have value undefined. If two or more formal
| parameters share the same name, hence the same
| property, the corresponding property is given
| the value that was supplied for the last parameter
| with this name. If the value of this last parameter
| was not supplied by the caller, the value of
| the corresponding property is undefined.

 

[Dmitry A. Soshnikov]

[...]

(variables, function declarations and formal parameters of functions)

A parameter creates a variable. If you are going to differentiate
parameters, use "variable declaration" as the first.

Yeah, I thought "declaration" word for "variables" goes without
saying. By "variables, function declarations" I meant "variables and
function declarations".

Also, of course there is differentiation between formal parameters and
variables behavior.

Dmitry.

 

[Dmitry A. Soshnikov]

[...]

As I was saying, the paragraph:

| Also, we know that the variable object is created and filled with
| initializing values every time on entering the context, and that its
| updating occurs at interpretation of a code

is a bit odd, grammatically. What are "initializing values"? I believe
you mean the for a function declaration, it would be that function and
for a variable, it would be `undefined`.

Thanks. Yep, exactly, but I don't wanna in this case to specify which
exactly values they got. The only info is essential in that sentence
is that at the moment of a code execution phase some data is already
available in the variable/activation object. Which means, variable
object (and is more exact -- properties of the variable object) got
some "initial values" without specifying which exactly values. Because
again, in detail this has been discussed in the second chapter devoted
variable object, so at the moment of reading the fourth chapter, a
reader should already know what is it, which values it have, how it
works and so on.

By the way, I used own concept of "runtime interpretation (of a code)"
phase in translation. Although, in spec there is a "code execution"
phase. I'd like to change it to "code execution", what do you think?

In that case, I would reword it to use standard terminology.

Upon entering an execution context, the variable object is created. For
each parameter variable, a property is created and given the initial
value `undefined`. For each FunctionDeclaration, a property with the
function's Identifier is created and given the value of the function.
For each variable declaration, a property is created and given the value
`undefined`.

Too complex. The main idea of the articles -- is the explanation with
not so dry approach as used in the specification, but clearly and in
the same time still with the scientific approach (which means without
simplifications in terminology, funny pictures and so on which are
used in many articles and even books on JavaScript). But I don't want
just copy the spec's sentences with "robotic" phrases (which of course
are useful exactly for technical specification). And again, all that
stuff about variable object is discussed in the second chapter, and
the fourth chapter is already about the scope chain and its features.

I would also mention the specification section number as a supporting
reference to the statements. In this case s 10.1.3 (Variable Instantiation).

Further chapters of this series depend on previous chapters (I wrote
this in Russian disclaimer and also in introductions of some
chapters). So at chapter 4 a reader already should know what is
"Variable Instantiation" and what are variable and activation objects.
A reader can find this information in the "Chapter 2. Variable
Object." where of course already there is a reference to 10.1.3.

Dmitry.

 

[Dmitry A. Soshnikov]

On Mar 31, 3:51 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:

[...]

but what is stored in the property is only a
reference to the object.

Yes, I touch this topic in the "Chapter 8. Evaluation strategy" (which
isn't translated yet; there discussed "by value", "by reference" and
"by sharing" (pointer values, addresses) strategies and which exactly
is used in ES and with which terminology) -- that the values of
variables/properties (i.e. name bindings) in case of assigning to
objects, are just reference values (addresses) to objects in memory;
but that's not for the chapter 4.

Dmitry.

 

[Dmitry A. Soshnikov]

[...]

| initializing values

Replaced with "initial values".

By the way, I used own concept of "runtime interpretation (of a code)"
phase in translation. Although, in spec there is a "code execution"
phase. I'd like to change it to "code execution", what do you think?

Replaced with "Code execution".

Dmitry.

 

[Garrett Smith]

It's true only for parameters, for which caller doesn't supply values.
If caller supply value for argument, during Variable Instantiation on
created property of VO with name Identifier will be assign value,
which provided by caller.

Right. Thanks.

 

[Garrett Smith]

There are still problems with the grammar. Look at the first paragraph:

| As we already know from the second chapter concerning variable object,
| the data of an executions context (variables, function declarations
| and formal parameters of functions) are stored as properties of this
| variables object.

That paragraph has more problems, still. Plural where not appropriate,
misuse and omission of particles.

| As we already know from the second chapter concerning *the* variable
| object, the data of an *execution* context (variables, function
| declarations*,* and formal parameters of functions) are stored as
| properties of *the variable* object.

 

[Dmitry A. Soshnikov]

There are still problems with the grammar. Look at the first paragraph:

| As we already know from the second chapter concerning variable object,
| the data of an executions context (variables, function declarations
| and formal parameters of functions) are stored as properties of this
| variables object.

That paragraph has more problems, still. Plural where not appropriate,
misuse and omission of particles.

| As we already know from the second chapter concerning *the* variable
| object, the data of an *execution* context (variables, function
| declarations*,* and formal parameters of functions) are stored as
| properties of *the variable* object.
--

OK, fixed; thanks.

Dmitry.