does anyone use Venkman?

Oh, that is quite natural. The parser first does one pass through the code searching for declarations. Then it does a pass through it executing the script.

Thus, first it finds the declaration of a. It instantiates a. It doesn't execute any code this time, though, so it doesn't give it a value. Then it goes on to b. Same thing here. Then c. Same thing.

No more declarations take place in the script, so it proceeds to the execution pass. It assignes the value 1 to the variable a. It assigns the value 5 to the variable b. It assigns the value 10 to the variable c.

Hi,

Finally, someone who actually uses Venkman!! :)

After altering the script many times and recalling a post I read awhile ago about variable scope in a function, which was demonstrated like this:

var b = "global b";
function f()
{
alert(b); //undefined. The local 'b' hides the global 'b' but local 'b' isn't defined yet.
var b = "local b";
}

f();



I finally arrived at that same explanation of what Venkman was doing: as you mentioned, javascript has to look ahead to see what variables are declared, and Venkman is following those steps. However, the tutorial that is recommended on the Venkman site and elsewhere:

http://www.svendtofte.com/code/learning_venkman/basics.php

makes no mention of that behavior. It says when you step past a statement like:

var a=1;

then 'a' will have the value 1. Did the Venkman design change?

In addition, I would think the ''look ahead" behavior of the debugger reduces its usefulness for stepping through code. How is traversing through those "look ahead" steps useful to a programmer? I don't see any reason why the debugger should trace those "look ahead" steps, which javascript has been programmed to do. Instead, I think the debugger should just give you the variable values after it silently does the "looking ahead". Am I misguided in wanting that? Is there a Venkman setting to turn off the "look ahead" steps?

Ah, actually, I don't use Venkman. Or, at least, I don't use it except for very knify situations where it's faster to use Venkman than it is to just inspect values by inserting alerts into the code. No, I just know JavaScript quite well.

This behavior is for many reasons necessary and is essentially a non-loss when it comes to performance. EcmaScript, as the standardised version of the language is named, has the behavior for a number of reasons. One of the reasons is that since the tokeniser and scanner always need to parse the source into an Abstract Syntax Tree (AST) it can perform the variable and function initialisations at the same time. By necessity it must read through the script for function declarations before executing it (Otherwise all function declarations would have to come earlier in the source than the usage of them, which kinda makes cross-calling between functions an impossibility), and to establish closures it needs to already know what locals are present before the execution of the function starts. So, performance wise it's a non-loss (actually a win in most cases) to parse the script for declarations before executing it, for scoping and function declaration reasons it must be done, and it gives the compiler the possibility to optimise some handling. All in all, it's something that simplifies and speeds up the actual code execution.

Note that this isn't something Venkman does. This is something ALL JavaScript implementations does. It's both in the specifications, making it standard, and it's logical and performant, so it's not something that would make for optimising losses either. Look at C - that language REQUIRES all variables and functions to be declared separately. JavaScript is a bit less strict, but it must still have them declared sometime, or take the cost of having to initialise them before it can use them each time, which will also lead to memory fragmentation.