Everything You Could Possibly Want to Know About Import Statements*

Everything You Could Possibly Want to Know About Import Statements*:

* Not really everything.

---

Imports Are Required**

In the AS2 days, you could get around having to write an import statement by simply using the fully-qualified class name within the class body (such as flash.display.Sprite as opposed to just Sprite). While you are welcome to use the fully-qualified class name as you write your code, import statements for each class are required in AS3.

So there’s not a whole lot of need to write fully-qualified class names, unless you happen to use two classes that share the same short name within the same class — perhaps if you are using Flash’s Camera class along with a 3D library’s Camera class.

---

** Unless the Class is in the Same Package

The exception to the previous rule is if the class you are using and the class you are writing are both in the same package. All classes in a package are implicitly available to each other, without an import statement.

It’s still not a bad idea to write the import statement anyway, because:

---

Import Statements Are Self-Documenting Code

By listing all of your imports, you create a sort of manifest of what other classes your class relies on in order to do its job. It may seem like a trivial thing, but this information can actually be quite useful. Consider the following class***:

package com.activetuts {
    import com.activetuts.SuperTrace;
    import com.activetuts.ActiveTween;
    public class QuickTip {
        public function QuickTip {
            var tracer:SuperTrace = new SuperTrace();
            tracer.log("Quick Tip");
            var tween:ActiveTween = new ActiveTween();
            tween.go();
        }
    }
}

*** Hopefully it’s obvious that this class is illustrative, not functional.

If you then use this QuickTip class, Flash will automatically make sure that the SuperTrace and ActiveTween classes are also compiled into the resulting SWF, because you used QuickTip, and QuickTip requires these classes.

Simple enough, but now consider more realistic classes which use dozens of other classes. If you need to know which classes are in use, a quick look at the import section can give you a decent idea. It’s not exhaustive, and it’s a little misleading even, but you’ll be hard-pressed to find someone who thinks that self-documenting code is a bad thing.

---

flash Classes Need Importing, But Are Not Compiled

There is a common misconception around the idea that using lots of classes necessarily means the file size of your SWF will increase. Normally, that’s true. But any class that starts with flash is one provided by the Flash Player, and will not have any effect on the size of your SWF. The byte code for, say, Sprite is contained in the Flash Player, and you’re simply registering the fact that you will use a Sprite, not bundling that byte code into your SWF. This is kind of the point of having the Flash Player.

I don’t expect you to believe me on this. I expect you to be slightly incredulous, and demand proof. I welcome you to prove this to yourself, by following these steps:

1. Create a new FLA and associated document class.

2. In the document class, write the minimum you need to actually define it as a document class:

   package {
       import flash.display.Sprite;
       public class Document extends Sprite {
           public function Document() {
           }
       }
   }
   

3. Open up the Publish Settings by pressing Option-Shift-F12 / Alt-Shift-F12 (or by choosing File > Publish Settings…).
4. Click on the “Flash” tab.
5. In the “Advanced” section, check the “Generate size report” option.
6. Also, in the “SWF Settings” section, check the “Export SWC” option, an uncheck the “Include XMP metadata” option (this last option removes a bunch of metadata from the SWF that inflates the size of the SWF and also make a mess of the size report we’ll be looking at) [...]