An ActionScript 2.0 Primer for ActionScript 1.0 Folk: Part Two

As promised in Part One of this article, in this second part we’ll examine the new class syntax malaysia live casino in ActionScript 2.0. Before we get started, if you have questions regarding general object-oriented concepts, including classes, then you may want to first check out these two articles malaysia mmc996:

The two articles discuss object-oriented concepts and creating classes in ActionScript 1.0, so you don’t necessarily need to memorize all the details of the ActionScript 1.0 techniques. But the articles should give you a pretty good introduction to what classes and objects are in a general sense. Once you have that background this article will likely make more sense to you.

ActionScript 2.0 Class Structure
While I could attempt to draw comparisons between ActionScript 1.0 “class” structure and ActionScript 2.0 class structure, it would likely be more confusing that clarifying. The truth is that ActionScript 2.0 class structure is fundamentally different than that of ActionScript 1.0. If you have any background in creating classes in other languages such as Java or C#, or even VB or PHP, then you’ll likely shout a loud hoorah for the new formal class structure in ActionScript. If you’re only prior experience with creating classes was with ActionScript 1.0, then don’t fret too much. You’re sure to find that although the syntax in ActionScript 2.0 is different, it is much more intuitive. After a week writing ActionScript 2.0 classes you’ll wonder how you ever managed with ActionScript 1.0.
To begin with, I’ll highlight a few of the key points of the new class structure and syntax, then we’ll look at some of them more closely.

* ActionScript 2.0 classes must be defined in .as files, and there can only be one class per file.
* ActionScript 2.0 classes are declared using the new class keyword followed by the name of the class and then the body of the class surrounded in curly braces. For example:
class Car {
// Class definition…
* ActionScript 2.0 classes can be in packages. ActionScript 2.0 supports the import keyword in order to import entire packages or select classes within packages.
* ActionScript 2.0 class members can be declared as public, private, and static.
* ActionScript 2.0 classes can extend other classes using the extends keyword in the class declaration.
* ActionScript 2.0 classes can implement interfaces.

Whew! If any of that sound scary or new to you, keep on reading. I’m going to explain each of these parts in more detail and with examples you can try on your own (assuming you have a copy of Flash MX 2004 or Flash MX Professional 2004.)

Defining ActionScript Class Files
If you’re not familiar with other languages such as Java or C# then storing classes in their own files may be a new concept. Particularly so if you’ve worked with ActionScript 1.0 in which you could define multiple classes not only within a single .as file, but even within an .fla file.
There are plenty of reasons why it’s advantageous to store all your classes, one per file, in external .as files. The core benefit is, of course, better organization. It’s just simply much easier to store, locate, maintain, and distribute your classes when they’re organized well. If you’re defining classes in all kinds of places, then it becomes a mess rather quickly. Of course, if you were only working with two or three classes, this would not necessarily pose a big problem. But ActionScript 2.0 ushers in a new paradigm for ActionScript. Developers can create and share libraries of classes that provide pre-built functionality. Rather than reinventing the wheel each time people can begin to build upon their own previous work and the work that others have contributed. You can see how Macromedia has already jumpstarted this with their set of standard classes that you can find in the First Run/Classes directory (and subdirectories) of your Flash MX 2004 installation.
So unlike ActionScript 1.0 classes, all ActionScript 2.0 classes absolutely must be saved in external .as files. Further more, these files must be saved such that the file name matches the name of the class. For example, if the class is named Car, then the file must be named

Working with Packages
Class files may be stored in packages. If you’re not familiar with packages (also called namespaces in the .NET world) they are simply a way of organizing your classes. There are two aspects to a package. First, the class definition must specify the package in its declaration. We’ll look more closely at that part in the next section. Secondly, the .as file must be saved in a corresponding directory or directories. For example, if the package for a class is com.person13 then the .as file for that class must be saved in a directory structure of com/person13.

There are two primary benefits to working with packages. The most obvious one is that it provides you with a way to organize your class files so that you can locate them quickly. For example, if you look in the set of classes that ship with Flash MX 2004 (in the First Run/Classes directory) you’ll see that many of the classes for the UI components are organized within the mx.controls package, and are therefore saved in the mx/controls directory. The second benefit of packages is that it helps to avoid possible name conflicts. You cannot have two classes with the same name in the same package for the obvious reason that Flash wouldn’t have a way of knowing which one you want to use. So if you didn’t use any packages and saved all your classes in the same directory you would potentially run into this problem. Of course, if you are writing all the classes then you have the ability to easily make sure you give each class a unique name. But when you download and install others’ classes, you don’t have that same control. So when classes are stored in packages it helps to make sure that these types of naming issues don’t occur. For example, the class Car in the com.person13 package and the class Car in the com.ejepo package don’t create any naming conflicts with Flash.

Defining Your Classpath
By default Flash looks first to the First Run/Classes directory within your Flash installation when trying to find class files. If it does not find a specified class in that directory then it next looks to the same directory in which the Flash or ActionScript document is saved.
The classpath is the list of directories to which Flash looks for class files. You can also specify additional directories for the classpath. And, if you want, you can change the order in which Flash looks to these directories. In order to edit the classpath choose Edit>Preferences, and then select the ActionScript tab. Click on the ActionScript 2.0 Settings to bring up the ActionScript Preferences dialog box. Use the + button to add new directories, the – button to remove directories, and the arrow buttons to reorder them.

Leave a Reply

Your email address will not be published. Required fields are marked *