I almost fell victim to this over the weekend, so thought I'd share a common JavaScript gotcha. What does the following line do?
var start = stop = null;
Most people will respond, "define a variable called start and a variable called stop and then set them both to null." That is generally correct, but not specific enough. What actually happens is that a local variable called start is defined and a global variable named stop is defined; both are then set to null. The var operator applies to start, not to stop because stop is part of the initialization (to the right of the equals sign). This code can be rewritten to create two local variables like this:
var start = null, stop = null;
Now, the var operator applies to both start and stop, creating two local variables (the comma indicates another variable being defined). It's little things like this that make me love JavaScript.
Who ever thought it was a good idea to make assignment to an undefined identifier within the scope of a function create a new global variable? When is this ever what the developer wants? The only use for the "var" keyword should be to create a local variable when a global variable already has that identifier. The global should defer to the local, not the other way around.
I know, I get confused going back and forth between PHP and JavaScript. In PHP, doing so causes a local variable to be created while in JavaScript it causes a global variable...of course you also have to declare global variables that you're using inside of PHP functions, which I find annoying as well. I guess we can't get it all. :)
Have been following with interest a proposal in the PHP developers mailing list, to include a patch for being able to create your own superglobals - basically global variables that show up everywhere without having to use that global keyword.
The consensus - virtually unanimous - is that this is a bad idea, because it would wreak havoc with existing code, by potentially opening the door to all sorts of scope confusion in existing code. Not sure I subscribe to that argument, but the other argument against, which I did like, was in support of the existing global keyword.
Reasoning is that with that in place, yes it can be a bit of a pain, but it means that in any function you can easily see which vars are local, and which are global. Which is I would say is a good thing, given that (like JavaScript) variables get created as and when they are used, rather than being explicitly declared.
Of course, a naming convention would easily make it obvious which vars were local and which global, but that's only going to be of help if everyone adheres, and that doesn't always happen in reality.
Anyhow, it looks like the global keyword is here to stay, and I don't think that's necessarily a bad thing.
Post Comment
Your e-mail address will never be shown, only your URL. Please, no HTML in your comments, as it will be automatically stripped out for security purposes.