From: Asen Bozhilov on
Garrett Smith wrote:

> 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.

From: Dmitry A. Soshnikov on
On Mar 31, 3:29 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:

[...]

>
> (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.
From: Dmitry A. Soshnikov on
On Mar 31, 3:40 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:

[...]

> 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.
From: Dmitry A. Soshnikov on
On Mar 31, 3:51 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
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.
From: Dmitry A. Soshnikov on
On Mar 31, 12:44 pm, "Dmitry A. Soshnikov"
<dmitry.soshni...(a)gmail.com> wrote:
> On Mar 31, 3:40 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>

[...]

> > | 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.