Zakas' new Quiz

[Garrett Smith]

Yet another JS Quiz:
http://www.nczonline.net/blog/2010/02/16/my-javascript-quiz/

I have a couple of comments on the explanations provided:
http://www.nczonline.net/blog/2010/02/18/my-javascript-quiz-answers/

Example #1:
I believe the explanation is that the postfix is matched, as in:

TOKENS: num1, ++, +, num2;

The ++ operator must apply to num1.

Example #2:
The explanation provided mentions scope, and that is totally wrong. The
scope of the anonymous function expression wrapped in the setTimeout is
(anonymous)[[Scope]] --> doIt [[Scope]] -- global [[Scope]].

The answer as to why `this.x` === 5 is explained by the fact that the
execution context for the nonstandard `setTimeout` method is global context.

The global object and the global variable object are the same object,
`this` is global object and `this.x` is the global object's variable `x`
is resolved .

This actually brings upon another issue related to IE, where the global
object is not the global variable object, but is instead a Host object,
as explained many years ago.
http://blogs.msdn.com/ericlippert/archive/2005/05/04/414684.aspx

Example #4 is correct explanation but instead of using the non-normative
(nonstandard) `String.prototype.substr`, it would have been nice to see
`String.prototype.slice` used instead. At least it it would be good to
comment on `String.prototype.substr` being nonstandard, and point to the
divergences in how JScript deviates from Ecma-262 recommendation.

 

[Asen Bozhilov]

Yet another JS Quiz:http://www.nczonline.net/blog/2010/02/16/my-javascript-quiz/

I saw this, but unfortunately seems my comment been moderate. However,
i cannot pass test for which author, doesn't specified concrete
environment, in which i can observe correct behavior.

If i see in practice `num1+++num`, I'll just stop to read this code,
because author doesn't give damn about readers of their code and
people which maintain this.

Example #2:
(anonymous)[[Scope]] --> doIt [[Scope]] -- global [[Scope]].

You are correct, but Global Object doesn't have internal [[Scope]]
property.

The answer as to why `this.x` === 5 is explained by the fact that the
execution context for the nonstandard `setTimeout` method is global context.

But what is matter calling execution context, when we talk about
`this` value in newly created execution context? I can't give answer
on this question, because `setTimeout` is host object. I don't know
how `setTimeout` invoke callback and what value pass for `this` value
on callback. This question is depend from caller, not from calling
execution context.

Example #4

I was give answer TypeError on this question.

 

[Garrett Smith]

Garrett Smith wrote:

[...]

I was give answer TypeError on this question.

For a system that does not implement a - substr - method for strings?

DMD Script, maybe?

 

[Thomas 'PointedEars' Lahn]

DMD Script, maybe?

The DMDScript source code in D indicates that it implements
String.prototype.substr():

<http://www.digitalmars.com/dscript/>


PointedEars

 

[Asen Bozhilov]

Asen Bozhilov wrote:

For a system that does not implement a - substr - method for strings?

Exactly. `String.prototype.substr' isn't part from any editions of
ECMA-262 standard. On this questions `TypeError' is possible answer.
Another possible answer is: "I don't know." and again is correct
answer.

| 2 Conformance
| [...]
| In particular, a conforming implementation of
| ECMAScript is permitted to provide properties not described in this
specification,
| and values for those properties,
| for objects that are described in this specification.

The standard permit methods like `substr', but these methods are
implementation depended, because concrete implementation can implement
in own way. I don't think methods like `substr' should be part from
quizzes, because confuse readers, especially when author of quiz isn't
specified concrete environment.

 

[Asen Bozhilov]

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.

 

[Jorge]

Example #2:
The explanation provided mentions scope, and that is totally wrong. The
scope of the anonymous function expression wrapped in the setTimeout is
(anonymous)[[Scope]] --> doIt [[Scope]] -- global [[Scope]].

Yep, every function carries its context with it, that's what closures
are about, and as soon as a reference to a function survives longer
than the context in which it was created (as when saved in the
setTimeout queue), a closure is born.

The answer as to why `this.x` === 5 is explained by the fact that the
execution context for the nonstandard `setTimeout` method is global context.

No. Not at all. It's explained by the fact that "this" is === window.
It has nothing to do with the execution context. It could have been
very well any other context !== the global one, and still "this" would
have been "window". E.g. if you wrapped it into yet another function.

 

[Jorge]

How can you explain:

var x = 10;
+++x;

There SyntaxError instead of runtime error.

As Richard said, the parser tries to math the longest sequence of
characters that makes sense. In this case ++ makes sense, but as soon
as the next character found is +, it stops making sense and throws.

 

[Jorge]

As Richard said, the parser tries to math the longest sequence of
characters that makes sense. In this case ++ makes sense, but as soon
as the next character found is +, it stops making sense and throws.

s/math/match/

 

[Asen Bozhilov]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

As Richard said, the parser tries to math the longest sequence of
characters that makes sense. In this case ++ makes sense, but as soon
as the next character found is +, it stops making sense and throws.

From which grammar rules `+y` isn't valid `UnaryExpression`?

And why in next example there runtime exception instead of
SyntaxError?

++ function(){}(); //ReferenceError
++ function(){}; //SyntaxError

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

 

[Jorge]

                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


From which grammar rules `+y` isn't valid `UnaryExpression`?

For the same reason that ++2 throws: +y is a number not a reference.

And why in next example there runtime exception instead of
SyntaxError?

++ function(){}(); //ReferenceError
++ function(){}; //SyntaxError

In Safari both throw a referenceError: Prefix ++ operator applied to
value that is not a reference.

`++` 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?

 

[Asen Bozhilov]

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

 

[Jorge]

`++` 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... ¿?

 

[Asen Bozhilov]

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.

 

[Jorge]

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.

Asen, in that example, obviously, the returned f() does not qualify as
an *inner* function.