Zakas' new Quiz
in [JavaScript]
|
Prev: FAQ Topic - Why does framename.print() not print the correct frame in IE? (2010-02-19)
Next: My Library TaskSpeed tests updated--MultipleIE has the IE6 problem,not My Library
From: Asen Bozhilov on 20 Feb 2010 12:37 Jorge wrote: > Asen Bozhilov wrote: > > `++` operator works with ReferenceType "13.2.1 [[Call]]", never return > > ReferenceType, which is logical because if [[Call]] return > > ReferenceType will be have reference to Activation Object of execution > > context which is finish. And AO cannot be marked as garbage collection > > when execution context exit. > > And ? It can return a reference to a function, isn't it? It can return reference value to any native object, but never return internal ReferenceType. I was explain why. If [[Call]] method return object from internal ReferenceType it is possible to stay reference to Activation Object of execution context which finish. | 13.2.1 [[Call]] | [...] | 2. Evaluate F's FunctionBody. | [...] | 4. If Result(2).type is throw then throw Result(2).value. | 5. If Result(2).type is return then return Result(2).value Both `throw` and `return` statements call internal GetValue and passed argument, which is from internal ReferenceType and it is result from evaluating right hand side Expression in statements `throw` and `return`.
From: Richard Cornford on 20 Feb 2010 13:03 Asen Bozhilov wrote: > Richard Cornford wrote: > >> That is an explanation, but not a full explanation because it does >> not state why +++ must be interpreted as the tokens ++ followed by >> the token +, rather than + followed by ++. The answer to that is >> in the spec, in the last sentence of the first paragraph of >> section 7, where it says "The source text is scanned from left to >> right, repeatedly taking the longest possible sequence of characters >> as the next input element". So given +++, the longest possible >> sequence of characters that can be a token is ++, leaving the last >> + to be the next token. > > How can you explain: > > var x = 10; > +++x; > > There SyntaxError instead of runtime error. A reasonable question as the interpretation should be the equivalent of:- ++(+x); - and as - (+x) - will evaluate as a (numeric) value rather than a Reference type, when step 5 in the Prefix Increment Operator algorithm (11.4.4) calls the PutValue function (8.7.2) PutValue should throw a Reference Error. However, in the section of the spec on errors we find:- | 16 Errors | ... | An implementation may treat any instance of the following kinds of | runtime errors as a syntax error and therefore report it early: | | * Improper uses of return, break, and continue. | * Using the eval property other than via a direct call. | * Errors in regular expression literals. | * Attempts to call PutValue on a value that is not a reference | (for example, executing the assignment statement 3=4). - where the last bulleted point refers to examples of calling PutValue where the pertinent argument is not a Reference type, and makes provision for reporting that as a syntax error rather than a runtime error. So the observed behaviour is at the discretion of the implementation, but is correct according to the specification. Richard.
From: Jorge on 20 Feb 2010 13:18 On Feb 20, 6:37 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: > Jorge wrote: > > Asen Bozhilov wrote: > > > `++` operator works with ReferenceType "13.2.1 [[Call]]", never return > > > ReferenceType, which is logical because if [[Call]] return > > > ReferenceType will be have reference to Activation Object of execution > > > context which is finish. And AO cannot be marked as garbage collection > > > when execution context exit. > > > And ? It can return a reference to a function, isn't it? > > It can return reference value to any native object, but never return > internal ReferenceType. I was explain why. If [[Call]] method return > object from internal ReferenceType it is possible to stay reference to > Activation Object of execution context which finish. > > | 13.2.1 [[Call]] > | [...] > | 2. Evaluate F's FunctionBody. > | [...] > | 4. If Result(2).type is throw then throw Result(2).value. > | 5. If Result(2).type is return then return Result(2).value > > Both `throw` and `return` statements call internal GetValue and passed > argument, which is from internal ReferenceType and it is result from > evaluating right hand side Expression in statements `throw` and > `return`. Ah, well, ok. But I still believe that your phrase "And AO cannot be marked as garbage collection when execution context exit" has nothing to do with it, for that's necessarily so when/if the returned value is an inner function's reference... ¿? -- Jorge.
From: Richard Cornford on 20 Feb 2010 13:27 Asen Bozhilov wrote: > Jorge wrote: >> Asen Bozhilov wrote: >>> `++` operator works with ReferenceType "13.2.1 [[Call]]", never >>> return ReferenceType, which is logical because if [[Call]] >>> return ReferenceType will be have reference to Activation >>> Object of execution context which is finish. And AO cannot >>> be marked as garbage collection when execution context exit. >> >> And ? It can return a reference to a function, isn't it? > > It can return reference value to any native object, but never > return internal ReferenceType. I was explain why. If [[Call]] > method return object from internal ReferenceType it is possible > to stay reference to Activation Object of execution context > which finish. <snip> While a native function call can never result in a Reference type the spec does include the following note:- | 11.2.3 Function Calls | | NOTE Result(8) will never be of type Reference if Result(3) is a | native ECMAScript object. Whether calling a host object can | return a value of type Reference is implementation-dependent. - which gives host objects the option of returning a Reference type. As a result the language's syntax rules cannot forbid constructs such as:- f() = 5; - or:- ++f(); - because it cannot generally be determined that - f - will not be a host object. On the other hand, with a construct such as:- ++((function(){ ... })()); - the parser is in a position to observe that the function that will be called is a native object, that the runtime error is inevitable (if the code were executed), and so take advantage of the provision in section 16 of the spec to report situations where inevitable runtime errors (relating to calling PutValue on non-Reference type) occur as syntax errors. (It is also reasonable for an implementation to exist specific to a given host environment, and to know that in that host there are no host methods that do return Reference types. In which case all constructs such as - f() = 5; - can be reported as syntax errors, as there is then no longer any potential for it being a successful construct.) Richard.
From: Asen Bozhilov on 20 Feb 2010 13:38
Jorge wrote: > Ah, well, ok. > But I still believe that your phrase "And AO cannot be marked as > garbage collection when execution context exit" has nothing to do with > it, for that's necessarily so when/if the returned value is an inner > function's reference? Yes but your point isn't related with returned value from ExecutionContext. Your point is related with 13.2 Creating Function Objects and internal [[Scope]] property, which refer VO associated with execution context in which FunctionDeclaration and FunctionExpression evaluated. For example if i use Function Constructor, internal [[Scope]] property of created function object will refer Global Object independ from calling execution context. You can easy observe this in Rhino 1.7R2, there `function' objects has property `__parent__', which is mimic of internal [[Scope]] property. var f = (function() { return new Function(); })(); print(f.__parent__ === this); //true And in this example, there are no any references to AO associated with execution context created from anonymous function. And therefore AO can marked for garbage collection, when execution context return value. |