From: Asen Bozhilov on 31 Mar 2010 02:46 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 31 Mar 2010 04:24 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 31 Mar 2010 04:44 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 31 Mar 2010 04:55 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 31 Mar 2010 05:44 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.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Ajax and browser caching Next: If you think you must modify the hash, think again |