AS2 OOP: Changes and Additions

by senocular   | filed under Object-Oriented Programming

Overview

With a new version number, there comes changes. With Flash MX 2004, not only did the application itself get a new number, a spiffy 2004 tacked on to the end of its name, but ActionScript got an upgrade too. The successor to ActionScript is here, ActionScript 2.0.

The most important development towards OOP is the new ActionScript 2.0. The changes it brings is not so much functional as it is cosmetic. ActionScript 2.0 adds to the language a new way to define and manage classes for your Flash movies. All classes are now written in external text files with an .as file extension which are then each accessed by Flash and automatically compiled into your swf files when publishing your movie (depending on whether or not the movie requires them).

[ flash movie accesses and includes class files on publish ]

In using such .as files, you'll need to make sure that they are in a location where your Flash movie can access them. This may involve adding directories to the classpath. If you aren't familiar with this process and wish not to get involved right now, just keep class files in the same directory as the Flash movie using them and you should be set.

Other scripting inside the Flash movie itself still retains the same form as ActionScript 1.0. The only real change with ActionScript 2.0 is the syntax in writing classes in those external as files. Some brand new keywords needed in making and handling classes created for ActionScript 2.0. These include:

• class
• static
• public
• private
• get
• set
• dynamic
• intrinsic
• extends
• interface
• implements
• import

Each will be covered in greater detail later on.

Even though ActionScript 2.0 is directed to programmers with prior programming backgrounds, learning how to use it if you're not one will help you become a better programmer on the whole. But before getting into just how it works, more changes outside of ActionScript 2.0 need to be addressed - such as those that come with the new Flash 7 format for .swf files.

New in Flash 7

The way Flash handles some variables when publishing a swf to Flash 7 is used in a movie has changed a little. These fairly minor, though important changes are the no. 1 cause of complications when porting Flash MX and earlier versions of movies to Flash MX 04. Understand that you do NOT have to convert your older movies for them to work in the new Flash player. Even though they are published to a lower format, the new player will treat them accordingly as based on the version of the swf. If they ain't broke, don't fix them. These changes are only for when publishing to the new Flash 7 format and applies to both ActionScript 1.0 and ActionScript 2.0 in that format. When working in ActionScript 2.0, chances are you are targeting the new player, so these need to be understood. Here's the run-down:

1. Case sensitivity
In a Flash 7 swf, all variables and keywords are case sensitive. This means that myvariable is not the same as myVariable. If used (as variables) Flash will interpret each to have their own separate values. This also means that attachmovie() will no longer attach a movie from your library onto the screen. The correct command is attachMovie() with a capital M.

If you've been a sloppy coder in the past, or just not keeping correct capitalization (that doesn't necessarily make you "sloppy"), this may be a problem. Now you'll have to be sure to maintain consistency with capitalization. With Flash objects and methods, color coding can help. With your own variables, you'll just have to keep to your guns and be consistent.

2. Undefined variable values have changed
When you use a variable that has not been previously defined somewhere in your script, Flash needs to assume a certain default value for that variable. This value is based on the context of where its first used; is it being used as a number? as a string? With Flash 6, this definition is 0 if used as a number and an empty string (""), even though technically the variable is still considered undefined. When using Flash 7, these default values have changed. Now, if an undefined variable is used as a number, a NaN is given; if as a string, the string "undefined" is given.

var name, job;
name = "George";
trace(name+" works for "+job);
// F6: "George works for "
// F7: "George works for undefined"
var value;
value++;
trace(value);
// F6: 1
// F7: NaN

3. String boolean value has changed
Now with Flash 7 strings, as long as they aren't empty, they have a boolean value of true. This means that when they are seen in a true/false situation, as long as the string has some value, it is seen as being true. This includes strings like "0". In Flash 6, strings are first converted to a number and then evaluated to being if that number was non-zero and false if not (i.e. if 0). Flash 6 will interpret "0" as being false; Flash 7 will not as it is not empty. To Flash 6 any non-numeric string is false. To Flash 7, as long as it has length, no matter if its numeric or not, it's true. Look at the following chart for examples.

4. Removed array lengthening with string indexing
Though you may have never known it or even made us of it, with Flash 6, you could extend the length of an array if you tried assigning a value to an index of that array outside of its length if using a string that was not a specific array index but could be parsed into one (i.e. a string that when used with parseInt would result in a number). The string "5tuna", for example, is not fully numeric so cannot specify a specific index of an array. However, when parsed into a number, that value becomes 5. If you tried to assign the index "5tuna" of an array with a length less than 6 in Flash 6, that array's length would then reach out to be 6 to account for the supposed index (even though, oddly enough, no actual value would be assigned to it). Now, when publishing your swf to Flash 7, that is not possible. Using strictly numeric strings, however, is still acceptable and will continue to work fine.

myList = new Array(2);
trace(myList.length); // 2
trace(parseInt("5tuna")); // 5
myList["5tuna"] = "anything";
trace(myList.length); // F6: 6, F7: 2
trace(myList[5]); // undefined

Now, with that out of the way, we can start focusing in more on Actionscript 2.0.

Strict Data Typing

To further aide debugging and assurance that you are in fact using your variables as you had intended for them to be used, ActionScript 2.0 has introduced strict data typing to the language. What this is, is the ability to specify what type a certain variable is when it's created (Number, String, MovieClip, etc.). Then, should you ever attempt to try to use it as a variable of an alternative type, an error will occur thereby isolating a confliction helping you to debug.

Strict data typing also allows for Flash to associate a variable with an object to help you with code hints when using that object. Before, this was only possible using underscore suffixes in your variable naming. Now you have the option of using strictly typed variables instead, allowing for more room in your own naming conventions. (Note: XML definitions will still be needed for code hints to function properly.)

Typing is always placed following a variable or function declaration. For variables, the type is placed immediately after the variable name separated by a colon (:). For functions, placement directly after the parameters list, also separated by a colon. Function types here, however, refer to the type of the value that the function is returning. If the function has no return, Void is used. Also, for functions, the parameters used can too be strictly typed.

var variableName:Type = value;

  function functionName(parameter:Type):returnType {}

  

The following is an example of some variables and a function being strictly typed. Notice that when a type is given a value not matching its data type, an error occurs.

var name:String = "Joe";
var age:Number = 21;
function message(msg:String):Void {
  trace(msg);
}
message(name); // traces "Joe"
message("Bob"); // traces "Bob"
message(age); // error: Type mismatch

Types are represented by using the object or class name of the type being represented. This includes your own custom classes as well as interfaces too (interfaces are considered a data type). Because age was of a type Number and not String, there was that Type mismatch error.

Variable types are not set in stone. Should you ever need to change the type of a currently typed variable, just re-declare the variable with var and retype it. That's all; its not as restrictive as it may initially seem. Example.

var value:Number;
value = 10; // ok
var value:String;
value = "ten"; // ok

Overall, this style of specifying type is very similar to the underscore naming convention (name_str vs. name:String) having come out of Flash MX. Only in this case, the type is not embedded within the variable name itself. It's used only in that single instance of declaration. Outside of that, the variable is used normally without any other real indication of type. This may be beneficial, or not. You may like having the variable name show its type. Either way, strict data typing in this manner also allows for code hints in using variables not defined in the underscore suffix convention.

[ code hinting from strict data typing ]

The use of strict data typing is only for ActionScript 2.0. If you use it with ActionScript 1.0, you won't get any errors (and you'll get code hints) but the variables its was used with won't function properly.

Some programming languages attain improved performance when using strict data typed variables. That is not the case with ActionScript. Strict data typing offer no advantages at runtime. They serve only as indicators for the compiler checks and for code hints in the authoring environment.

It may seem like a lot of extra work to set this up, but strict data typing is not required. It does, however, help you manage your variables. It's also good programming practice so it's recommended that you use it.

ActionScript Compiler

What makes all these new features/behaviors possible, this including the introduction of ActionScript 2.0, is Flash's new robust compiler. A compiler is a program that changes human written code into a program or a file which is more computer friendly or made of "computer code". In Flash's case, it takes your ActionScript and your Flash movie and converts them into swf-worthy byte code.

[ actionscripts and flash movie compiled into swf ]

For a compiler to properly work, however, it also needs to be a good error checker. It needs to recognize when you've screwed up in your coding so it can properly create a working .swf file. Many of the new features in Flash MX 2004, like strict data typing, help this error checking process. They help you make code that helps the compiler let you know when you've done something wrong.

This new compiler, with the introduction of ActionScript 2.0, is also handling the process of converting the code written in the new syntax into proper ActionScript 1.0 code for the .swf file. Because it's doing that conversion, you'll have to realize sometimes that some of these new features won't necessarily be there when playing your Flash movie. Many are just a part of how the compiler interprets your code before converting to ActionScript 1.0 and making a playable movie. You may want to familiarize yourself with the limitations of scripting in ActionScript 1.0 when playing a movie to help you better understand the limitations of ActionScript 2.0 when playing a movie since they still apply.

Strict Data Typing is a good example of this. Data typing your variables does two things: code hints (don't effect a running movie) and checking type compatibility between a variable and a possible value its being assigned. This checking is handled completely by the compiler. Since the compiler is not running when playing a .swf, its possible that, if not caught by the compiler when your movie is published, a certain value of one type can be assigned to a variable of a different type without error. Here's one way to do just that and not have the compiler error.

var value:Number = 1;
trace(value); // 1
var tricker = "value";
this[tricker] = "one"; // no error
trace(value); // one

Using associative array syntax with a variable, the compiler is unable assume it knows what the value of tricker will be. As a variable, it could actually be anything at anytime, so there's never a guarantee that it will be a reference to value and therefore the compiler can't call an error because it doesn't can't rightly associate that assignment with any particular value type.

The same applies to most every other new ActionScript 2.0 feature. Chances are that there can be ways which bypass the compiler and slip through to a final swf without being caught. Though Flash MX 2004's new compiler has greatly improved and helps even more in its aide to create correct, well designed applications, it is not perfect and you may have to account for that.

Still, ActionScript 2.0 does hold some wonderful new advancements in defining OO classes. Its about time they get addressed.

That wraps up this tutorial. A huge thank you to all of you who buy kirupa's books, became a paid subscriber, watch the videos, and/or interact on the forums. Your support is what keeps writing like this online! 😇

This tutorial was written by senocular, also known as Trevor McCauley. He has been one of this community's most generous teachers since the early Flash days, and he is still around: find him on senocular.com and on the forums.