So how did you score on the JavaScript Web Quiz?Let us know and we'll compare scores

Please PM us if you have anything of interest for the next issue, and happy reading! - [Paul & [URL="http://www.sitepoint.com/forums/private.php?do=newpm&u=184222"]Pullo](http://www.sitepoint.com/forums/private.php?do=newpm&u=158377)

Creating a quizz is a very interesting way to promote your book. I have to say that my score was 50% (or 10) which I think is great because I haven't used Javascript in one year. It should have been 11 but I was a bit too quick to click on one of the answers

It would be fun to examine some of the questions and find out why the answer is what it is.

I rushed through it the first time and got just under half of them right. They are all good examples of how NOT to write JavaScript as many of the answers are not obvious unless you take the time to properly examine the code.

To start off on why the code in the questions give those results, here's my analysis of the first twelve questions.

var foo = function foo() {
console.log(foo === foo);
};
foo();

The relevant part of this is foo === foo which is true

function aaa() {
return
{
test: 1
};
}
alert(typeof aaa());

A return without a value after it returns undefined (and the object is a different statement as a linefeed terminates a return statement.

So even though go() runs foo.baz.bar() the function bar() runs in global scope when called using go() and in baz scope when called as foo.baz.bar()

I got about half of them wrong the first time through. It was only when writing up the explanations that I actually looked at them closely enough to figure out the reasons why the answers were what they are.

I think the word "scope" is ambiguous. There are a couple different things in JavaScript that can be thought of as "scope".

There's the variable lexical environment. This determines what variables a function has access to. This is probably what we most commonly think of as "scope".

And there's the this binding. This determines what the value of "this" will be during a particular function execution. This seems to be what felgall is referring to when he says "scope".

When we invoke bar/go as a function and not as a method, then the global object is implicitly bound to "this", so return this.x returns the global x (3). But when we call bar as a method -- foo.baz.bar() -- then baz is bound to "this", so return this.x returns baz.x (1).

[QUOTE=Jeff Mott;5634354There are a couple different things in JavaScript that can be thought of as "scope"..[/QUOTE]

I actually refer to both.

With regard to lexical environment - go() is defined within global scope and bar() is defined within baz scope.

In the example being discussed the this binding is binding "this" to the object whose lexical scope the function is running in.

Can you provide an example of how the code being discussed could be modified so that "this" binding does not match the lexical scope of the object the function is called from (without using bind, call or apply).

With regard to lexical environment - go() is defined within global scope and bar() is defined within baz scope.

"go" is defined in the global lexical environment, yes. But, "bar" is not defined in the "baz" lexical environment. In fact, there's no such thing as the baz lexical environment. A new variable lexical environment is created when we create a function. So the function bar creates a new variable lexical environment, but the only relationship baz has to bar is that bar is a property of the object baz.

Talking of 'lexical environments', the guy who wrote the JS test in question also wrote an interesting article on JavaScript's Execution Context. He also mentions hoisting and how that works behind the scenes. It's a good read for anyone who want's to dive into this stuff in a little more depth.

"go" is defined in the global lexical environment, yes. But, "bar" is not defined in the "baz" lexical environment. In fact, there's no such thing as the baz lexical environment. A new variable lexical environment is created when we create a function. So the function bar creates a new variable lexical environment, but the only relationship baz has to bar is that bar is a property of the object baz.

I have always though of objects and functions in JavaScript as being effectively the same thing. I haven't come across any instance where they behave differently.

So basically what you are saying is that because "baz" is an object rather than a function that the correct terminology is different even though the end result is the same.

I have always though of objects and functions in JavaScript as being effectively the same thing. I haven't come across any instance where they behave differently.

So basically what you are saying is that because "baz" is an object rather than a function that the correct terminology is different even though the end result is the same.

It's much more than terminology. You've probably heard the phrase, "JavaScript has function scope." The "scope" being described in that phrase is the variable lexical environment. Functions create a new lexical environment (scope), plain objects do not. The most we can say about Baz is that it's one among many possible objects that could be bound to "this".

Based on this and other things you've written, I think you're under the impression that variables and object properties are the same thing. For global variables, that's actually true. But that's the only time it's true. Variables declared inside functions don't belong to any object, nor do new object properties create new variables.

Talking of 'lexical environments', the guy who wrote the JS test in question also wrote an interesting article on JavaScript's Execution Context. He also mentions hoisting and how that works behind the scenes. It's a good read for anyone who want's to dive into this stuff in a little more depth.

... we know from the creation stage that functions are created on the activation object before variables, and if the property name already exists on the activation object, we simply bypass the decleration.

and that var foo is effectively ignored, as the property name already exists on the activation object.

Or did I get that wrong?

Looks like you got that exactly right. Both the David Shariff blog post and the ECMAScript spec say that function declarations are evaluated before variable declarations, so the var foo statement is ignored.

Thanks Jeff. I just wanted to be sure that I had understood that correctly.

You mentioned the ECMAScript spec. Do you know of any accessible way to browse that?I downloaded the current version, but a search for "hoist", "function declaration", "variable declaration" and "activation object" didn't turn up anything.Could you point me to the bit where I can read that function declarations are evaluated before variable declarations.

Thanks Jeff. I just wanted to be sure that I had understood that correctly.

You mentioned the ECMAScript spec. Do you know of any accessible way to browse that?I downloaded the current version, but a search for "hoist", "function declaration", "variable declaration" and "activation object" didn't turn up anything.Could you point me to the bit where I can read that function declarations are evaluated before variable declarations.

Appreciate the help.

It's interesting. "Hoisting" is certainly established terminology, but that term doesn't appear to have originated from the spec. It's nowhere in there. "Activation object" isn't in there either. I'm not sure where that term came from. What the blog post calls the activation object appears to be what the spec calls the VariableEnvironment.

"FunctionDeclaration" is in there, but without the space. They write it in upper-camel case, a formal name of a grammar symbol.