Frank is a very skilled illustrator and 3D artist who recently held a contest on Twitter for people who would retweet him. I was one of the fortunate winners of the contest.

Included in the package was a SWEET envelope that Frank personalized for each winner with random (and rather cute) artwork. Inside the package was a button pack with buttons by Royal Buttons Custom Buttons. There was also an unbent copy of the package art, and a sweet random drawing on nice card stock with a personal note from Frank, thanking the winner for participation.

Frank said he would also have some future contests, so even though this one is over, there could be some stuff up for grabs later.

The thing to understand about JavaScript is that it isn't compiled for the most part. (This is not exactly true for ActionScript because of the introduction of classes in ActionScript 2.0, however, the runtime script remains the same. You might argue that it compiles into a *.swf file, but in reality, that is the combination of everything that has to do with the Flash file. The ActionScript still remains live.) It's good that it isn't compiled though, because this allows for much more dynamic, expressive coding.

So, if it isn't compiled, how does it work? Browser-based JavaScript code is all executed at first calling, nothing is compiled or cached in a scope until it is called (except AS2 & AS3 classes). It works this way because, with the exception of basic, immutable variable types: strings, booleans, numbers, and 'undefined', every variable in JavaScript is an object. This includes 'null' and functions ('null' is technically a basic variable, but is reported as an object in JavaScript). Since functions are objects, this means their value in memory is also like an object and names are only assigned by reference. Lets see how this works:

//bob first initialization
function bob()
{
	alert('bob');
}

//set jan to bob via reference
var jan = bob;

//set bob to another function
function bob()
{
	alert('newbob');
}

jan(); //alerts 'bob'
bob(); //alerts 'newbob'

This where things can be very confusing to people who are used to other languages where functions are just functions and can only be written once to a variable name at compile time. In order to understand better, let's write the same code again with anonymous functions:

//bob first initialization
var bob = function()
{
	alert('bob');
};

//set jan to bob via reference
var jan = bob;

//set bob to another function
bob = function()
{
	alert('newbob');
};

jan(); //alerts 'bob'
bob(); //alerts 'newbob'

This is how functions are actually assigned in JavaScript. The traditional C style that was seen in the previous example is translated at runtime into something like the above. So, when you code JavaScript, imagine instead that all functions are really variable pointers to anonymous functions in memory. (ActionScript 3.0 in strict mode attempts to stop this sort of behavior by warning you when your code tries to overwrite variables that have already been set. While this is good for heavier languages, I think it is moving away from what makes ECMAScript really dynamic in the first place.)

At this point, you might be asking: "Why is all this important to the execution order of JavaScript?". This gives you background as to why JavaScript doesn't execute anything until runtime. In light of this, there is one thing JavaScript does to speed things up that is VERY important to understanding its execution order: JavaScript caches declared functions before any other variables, after this, it goes back to the top of the scope and runs variable definitions and functions calls in the order that they appear. This is where the confusion begins for the uninitiated.

Let's say for example that you have a function that returns a value from a passed variable. You might want to assign a variable to the result of that function like so:

var newNumber = secondPower(5); //25

//first definition of function
function secondPower(n)
{
	return n * n;
}

This works because the function was cached before the variable was assigned. However, doing things this way in your own code is a TERRIBLE idea because it can cause more problems than it solves. Lets look at an example of where this might fail. Remember our previous example where we assigned the anonymous function to a variable name? While in that example, it worked perfectly, it actually causes a strange thing to happen to execution order:

var newNumber = secondPower(5); //error, secondPower is not defined yet

//some parsers would not even get this far due to the above error
//thrown errors in ECMAScript halt the execution scope they are in
var secondPower = function(n)
{
	return n * n;
};

var newNumber2 = secondPower(5); //25

This error happens because when the parser came through, it cached the anonymous function before anything else, but not the variable name assignment to the anonymous function. Therefore, when we called 'secondPower', it had not been assigned yet and the first calling was undefined and possibly threw an error. It is important to remember that the bad thing that happened here was not the fact that we assigned a variable name to an anonymous function in place of the classic C way to declare a function, but rather the bad idiom of calling a function before it is assigned. Anonymous functions offer huge benefits to ECMAScript and are not inherently bad.

Other problems can arise from calling functions before they are declared even if the function is written in the classic style. Perhaps the function we use for variable assignment requires an outside variable to function properly. This would cause an error if the function was called before the assignment of the dependent variable took place:

var newNumber = multiplyNumber(5);
//multiple is not defined yet, incorrect result with possible error 

var multiple = 2;

//this is cached and available before all other variables
function multiplyNumber(n)
{
	return n * multiple;
}

As we can see here, an error would occur in our variable assignment because even though the function was properly cached, its dependent was not assigned yet and the function could not execute properly.

So, knowing this, what should you do to avoid these errors? Here is a quick list to help you when writing your code:

• Never call a function before it is declared
• Declare all variables in a execution scope as soon as possible
• Only assign variables to a function result after all functions and other variables have been declared

Just to reiterate, let's look at how a good code setup should be writen:

//declare all variables as soon as possible
var newNumber, multiple = 2;

//declare all functions before calling them
function multiplyNumber(n)
{
	return n * multiple;
}

//finally, set variable values that require function results
newNumber = multiplyNumber(5); //10

Declaring your variables and functions in this way will allow you to use more expressive methods to set functions and will most importantly avoid errors. For some further reading, check out Douglas Crockford's recommendations on JavaScript coding conventions.

While I mostly mentioned JavaScript in this Article, the majority of these principles and Douglas Crockford's suggestions apply to ActionScript as well.

There are a number of ways to identify an array in JavaScript. Checking for properties of an array isn't totally accurate because you can add any named member to an object to imitate an array. Checking for 'instanceof Array' works most of the time but could be tricky in some implementations of JavaScript.

Mark Miller of Google gives us a solution that is standard to the ECMAScript documentation:

Object.prototype.toString.apply(value) === '[object Array]';

What this essentially does is take the standard Object method "toString" and applies it to the passed argument (which is your array you are checking). This makes sure that it reports itself according to standard, which all real arrays should. We can implement it in an easy checking function that returns a boolean:

function isArray(a)
{
	return Object.prototype.toString.apply(a) === '[object Array]';
}

Props to Douglas Crockford because I read about this on his blog. There is also some further discussion there on using this method and i recommend reading it.

As a bonus of sorts, this also works in ActionScript 2.0 and ActionScript 3.0.

Error handling with JavaScript is somewhat lackluster. With this in mind, you should do your best to catch and handle errors and avoid sending them to the end-user. In order to prevent errors and allow for scalability, you should test for functions that aren't present in the script where you are calling them.

Lets say for example that you have downloaded a JavaScript library named "bob.js" and it contains just a main function named "bob". To keep things clean, you might load this file separately. (Of course this is a bit unrealistic, no one would make a separate file for one function, but for the sake of example, bear with me.) Your loading code might look like this:

<script type="text/javascript" src="bob.js"></script>
<script type="text/javascript" src="mycode.js"></script>

So, correctly, we have loaded the "bob" library first and our code second.

For the sake of example and understanding, lets suppose that the "bob" function just returns a simple math result. It isn't important what the bob function does, but it might be easier for some to understand if we had a real example:

//bob.js
function bob(n)
{
	return n * n;
}

Now this takes us to our real example. Given that we have the function "bob" in another file, we want to use it in our own code, "mycode.js". When the page loads, we want to add a div tag with some text that has a number in it. We are going to use the "bob" function to return the number to the power of 2 and write it:

//mycode.js
window.onload = function()
{
	//the starting number
	var oldNum = 43;
	
	//make the number we are going to write
	var newNum = bob(oldNum);

	//set the body tag to a variable
	var body = document.getElementsByTagName('body')[0];
	
	//make the div container
	var myDiv = document.createElement('div');
	
	//create the text container
	var myText = document.createTextNode(newNum);
	
	//add the text to the div
	myDiv.appendChild(myText);
	
	//add the div to the body
	body.appendChild(myDiv);
}

While the above code could be written quite a bit smaller, it works well and it is plain what is happening. You run into an issue however when the "bob.js" file isnt present. When you run into an error in JavaScript, it usually kills the chain the function or event is called in. So in the above instance, as soon as it hit the second variable, and the bob code wasn't present, the code would simply halt on error and nothing would display on screen, potentially breaking many other things in the process.

This brings the issue of error handling and function testing. One of the tools that we do have in JavaScript is the try/catch(/finally) statement. It is very handy for areas of code that can be error prone or have outside influence on the application. We could fix our example by adding a try/catch statement that would have a backup variable in case the "bob.js" isn't present:

//mycode.js
window.onload = function()
{
	//the starting number
	var oldNum = 43;
	
	//make the number we are going to write
	try {	
		//works if bob is present
		var newNum = bob(oldNum);
	} catch(e) {
		//catches the error if bob is missing and provides an alternative
		var newNum = oldNum;
	}

	//..etc
}

This will effectively remove the chance for error if "bob.js" isn't present. However, the try/catch statement takes a bit of a performance hit due to all it is designed to do. When simply testing for functions, I feel it is a bit verbose.

My personal preference is just to test for the existence of the function before I attempt to call it. This way you don't spend the CPU time calling the function, getting the failure, sending the error, catching the error, then running the error block. When testing for a function, it's usually best to make sure it is actually a function rather than simply checking for it to be not undefined. This is doubly important in situations where you are using multiple libraries or working with a lot of people on the same file. Your code and their code could have the same name for two different types of objects. JavaScript has no overwrite protection even on its own built in functions unless specific platforms add it in, therefor you must take it upon yourself to check.

Checking for the existence of functions can be done easily using the typeof operator in JavaScript. Many times, I code that simply checks for "undefined" or not, then lets the code run. As mentioned above, this still leaves some potential for errors in your code. Granted, there will always be margin for error, but the goal is to make habits that minimize it and help you the real issues. Therefore I think it is better to make sure your function is actually a function. The same code we used with the try/catch statement can be written similarly with the typeof checking:

//mycode.js
window.onload = function()
{
	//the starting number
	var oldNum = 43;
	
	//make the number we are going to write
	if(typeof bob === "function") {	
		//works if bob is present and is a function
		var newNum = bob(oldNum);
	} else {
		//if bob is not present, provides an alternative
		var newNum = oldNum;
	}

	//..etc
}

This has better performance than the try/catch statement and gives you a better idea where an error could be if it occurs. However, we could write this even shorter to make the code a little cleaner using a ternary operator:

//mycode.js
window.onload = function()
{
	//the starting number
	var oldNum = 43;
	
	//make the number we are going to write
	//if bob is present and is a function, make number
	//if bob is not present, provides an alternative
	var newNum = (typeof bob === "function")? bob(oldNum) : oldNum;

	//..etc
}

One last thing to mention when using typeof. It will throw an error if you are testing for a function inside of a nonexistent parent. So, say "bob" is an object, with a subobject "math", with a method called "double". If we test for "bob.math.double" and "bob" doesn't exist, JavaScript will throw an error with the typeof operator. To avoid such errors you could test for each segment of the method's parent chain before testing for the method itself:

//mycode.js
window.onload = function()
{
	//the starting number
	var oldNum = 43;
	
	//make the number we are going to write
	if(typeof bob === "object" && 
	   typeof bob.math === "object" &&
	   typeof bob.math.double === "function") {	
		//works if bob is present and is a function
		var newNum = bob.math.double(oldNum);
	} else {
		//if bob is not present, provides an alternative
		var newNum = oldNum;
	}

	//..etc
}

This seems a lot longer given the possibilities of nested objects, but doing it this way also prevents the issue of same-named objects clobbering each other and sneaking in to create errors. If you are really confident with your code and have no outside workers/code coming in, you could skip the middle statements and just test for the parent object.

There we have it. This method of function existence checking has saved me lots of time and has created some interesting idioms for projects where external code may or may not be present. Enjoy!

This means that, on the surface, the only way to prevent time line variables from being constantly created is an init function of sorts. (ActionScript 2.0 has a pseudo global object which is the main time line of a movie level, and a totally global object named _global.) This also means that private variables are restricted to the creation of object classes. I personally get annoyed at times with classes in ActionScript. One of the things that has always bugged me with ActionScript 2.0 and the introduction of classes is that they are hard to make portable. (I work on no less than 3 computers in a single week, and 4-5 when on business trips, so portability is paramount to my work.) Rather than being able to simply include the classes in the same folder as the flash working file (*.fla), you must specify where on the computer the includes are. This is just annoying if you work on the file on several different computers. There are a couple of ways to avoid naming the class include folder on each computer, but they are as much of a pain as the default method. Fortunately, there is a solution.

To reiterate, while this works in JavaScript and ActionScript 3.0, it will not in ActionScript 2.0:

(function(){
	//statements
})();

var myFunc = (function(){
	var hiddenVar = "hidden";
	return function()
	{
		return hiddenVar;
	}
})();
hiddenVar		//undefined
myFunc.hiddenVar; 	//undefined
myFunc(); 		//returns "hidden"

The good news about ActionScript 2.0 is that it retains the ability to pass anonymous functions as variables to another function. Like so:

var myArray = [5,1,6,23,15];
var sortedArray = myArray.sort(function(a, b){
	return a - b;
});
trace(sortedArray); //returns [1, 5, 6, 15, 23]

Knowing this, we can emulate anonymous function closures in ActionScipt 2.0. First we will create a global function that returns the function passed to it.

_global.closure = function(f)
{
	return f;
}

To use it, you treat it the same as you would the parenteses in the javascript idiom:

closure(function(){
	//statements
})();

Changing the name to something shorter will make this more practical and the code a little cleaner.

_global.$ = function(f)
{
	return f;
}

$(function(){
	//statements
})();

Given this new ability, we can now apply anonymous closures to our script without littering the time line object with useless variables.

Lets use a hypothetical situation to illustrate how we might use the anonymous closure. In this script, we want to make 5 buttons that each need to trace their respective number when you click them. We could code each button individually, but that is messy and doesn't promote good code reuse. Instead, lets make a loop that makes all the buttons work, in addition to making it easier to add more buttons.

for (var i = 1; i <= 5; i++)
{
	//for each button
	this["click" + i + "_btn"].onPress = $(function(n){
		//return a function that has access to n via
		// a closure
		return function()
		{
			//trace the number passed to the parent closure
			trace(n);
		}
	})(i); //pass in current loop iteration for caching
}

Now when you press click3_btn, it will trace '3' and click5_btn, '5'. In this way, we avoid creating useless variables inside each button, and we didn't have to create a singular use function.

Earlier I mentioned my slight distaste for how classes were implemented in ActionScript 2.0. Let me first caveat this statement by saying they are extremely useful and are wonderful for individuals or teams that have good version networks and servers. Just for myself and the smaller applications I write, I prefer portable objects. Lets see how we would write a singleton object with private variables and functions:

var bob = $(function ()
{
	//---------------------------
	//private variables
	var secret = "you found me";
	//---------------------------
	//private functions
	function compare(a, b)
	{
		return a > b;
	}
	//---------------------------
	//constructor
	var Bob = {
		//---------------------------
		//public members/variables
		works		:true,
		getSecret	:function()
		{
			return secret;
		},
		getCompare	:function(a, b)
		{
			return compare(a, b);
		}
	};
	//---------------------------
	//return object
	return Bob;
})();
//test
trace(typeof bob) 		//returns object
trace(bob.works);		//returns true
trace(bob.getSecret());		//returns the string: you found me
trace(bob.secret);		//returns undefined
trace(bob.getCompare(1, 2));	//returns false
trace(bob.compare(1, 2));	//returns undefined function

As you can see with the tests, we have a singleton object with private functions and variables as well as public methods and members. With a little work, using the prototypal inheritance method, we can make this a reusable pseudo class:

var Bob = $(function ()
{
	//---------------------------
	//private variables
	var secret = "you found me";
	//---------------------------
	//private functions
	function compare(a, b)
	{
		return a > b;
	}
	//---------------------------
	//constructor
	var Bob = function ()
	{
		//---------------------------
		//public members/variables
		this.works = true;
	};
	//---------------------------
	//public methods
	Bob.prototype.getSecret = function()
	{
		return secret;
	};
	Bob.prototype.getCompare = function(a, b)
	{
		return compare(a, b);
	};
	//---------------------------
	//return constructor
	return Bob;
})();
//invoke
var mybob = new Bob();
//test
trace(typeof Bob);		//returns function
trace(typeof mybob);		//returns object	
trace(mybob.works);		//returns true
trace(mybob.getSecret());	//returns the string: you found me
trace(mybob.secret);		//returns undefined
trace(mybob.getCompare(1, 2));	//returns false
trace(mybob.compare(1, 2));	//returns undefined

So, with a single global function, we can bring the magic of anonymous function closures to ActionScript 2.0. Enjoy!

The problem that comes with this method is the advent of ActionScript 3 with Flash CS3/Flex 2 and the rising use in namespaces by JavaScript developers (myself included). Both encour a heavy usage of object methods instead of one-off functions. Dynamically calling singleton functions is easy, you can just use subscript notation, e.g. object[‘member/method’]. What you can’t do with this method is pass it any dot syntax and expect it to work e.g. object[‘subobject.method’]. The subscript notation is only meant to work one level. So the previous example won’t work. In order to fix this issue and to make sending object methods/members in a single string a little easier, I wrote a function that takes a string and a base object (the default is the window object if no object reference is passed) and returns the method/member. (I know at this point that some will simply direct me to ECMAScript’s built in eval() function, but I personally avoid using it at all costs as it can have unintended, and unsecure results. I’ll let Stephen Chapmen tell you because this article is about something else.)

The function is executed somewhat simply by splitting the string at the dots and adding them as subscripts to one another in order. However, there are some other pieces to it that make it a little more friendly to mistakes and general usage.

function parseNameSpace(s , o)
{
	//default to window if no object sent
	var w = o || window, a;
	
	//reutrn if parsing not necessary or not a method
	if ( s.indexOf('.') == -1 )
	{
		return (typeof w[s] === "undefined") ? false : w[s] ;
	}
	
	//make array for looping through
	a = s.split('.');
	
	//run though members / methods
	for (var i = 0,l = a.length; i < l; i++)
	{
		w = w[a[i]];
	}
	
	//return object if it is valid, or return false
	return (typeof w === "undefined") ? false : w ;
}

The function takes two variables, first the string that you want to parse to an object member, and the second optional base object. The first variable w looks for the object “o” and if not found, defaults to “window” which is the default parent object of browser based JavaScript. (You could change it to “this” and it would work in ActionScript as well). Second, we check to see if the passed string has any dots in it. If not, we check to see if it is a regular function. This way you could use this function as a catch all even if you aren’t always passing nested functions. If it isnt a member of the window object, false is returned. If it does have dots, we split them into an array, and loop through it, making each a member of the previous using the subscript notation. Finally we check to see if the result is valid, and we return false if it isn’t, or a reference to the object itself.

Let’s take a look at a simple way to use it. Lets say we have an object literal with a subobject, and a method inside that.

var obj = {
	innerObj: {
		func: function(){
			return "worked";
		}
	}
}

Then we retrieve it via string with the function.

var objFunc = parseNameSpace("obj.innerObj.func");
alert(objFunc()); //shows "worked"

This should work most places as long as you are mindful of function scope. Enjoy!