Importing packages

If you want to use a class that is inside a package, you must import either the package or the specific class. This differs from ActionScript 2.0, where importing classes was optional. For example, consider the SampleCode class example from earlier in this chapter. If the class resides in a package named tutorial.samples, you must use one of the following import statements before using the SampleCode class:

import tutorial.samples.*;

or

import tutorial.samples.SampleCode;

In general, import statements should be as specific as possible. If you plan to use only the SampleCode class from the samples package, you should import only the SampleCode class rather than the entire package to which it belongs. Importing entire packages may lead to unexpected name conflicts.
You must also place the source code that defines the package or class within your classpath. The classpath is a user-defined list of local directory paths that determines where the compiler will search for imported packages and classes.

After you have properly imported the class or package, you can use either the fully qualified name of the class (tutorial.samples.SampleCode) or merely the class name by itself (SampleCode).
Fully qualified names are useful when identically named classes, methods or properties result in ambiguous code, but can be difficult to manage if used for all identifiers. For example, the use of the fully qualified name results in verbose code when you instantiate a SampleCode class instance:

var mySample:tutorial.samples.SampleCode = new tutorial.samples.SampleCode();

As the levels of nested packages increase, the readability of your code decreases. In situations where you are confident that ambiguous identifiers will not be a problem, you can make your code easier to read by using simple identifiers. For example, instantiating a new instance of the SampleCode class is much less verbose if you use only the class identifier:

var mySample:SampleCode = new SampleCode();

If you attempt to use identifier names without first importing the appropriate package or class, the compiler will not be able to find the class definitions. On the other hand, if you do import a package or class, any attempt to define a name that conflicts with an imported name will generate an error.
When a package is created, the default access specifier for all members of that package is internal, which means that, by default, package members are only visible to other members of that package. If you want a class to be available to code outside of the package, you must declare that class to be public. For example, the following package contains two classes, SampleCode and CodeFormatter.

package tutorial.samples {
    public class SampleCode {}
    class CodeFormatter {}
}

The SampleCode class is visible outside the package because it is declared as a public class. The CodeFormatter class, however, is visible only within the sample package itself. If you attempt to access the CodeFormatter class outside of the tutorial.samples package, you will generate an error.

import tutorial.samples.SampleCode;
var mySample:SampleCode = new SampleCode(); // okay, public class
var myFormatter:CodeFormatter = new CodeFormatter(); // error

If you want both classes to be available outside the package, you must declare both classes to be public and place them in separate source files. You cannot apply the public attribute to the package declaration.

Fully qualified names are useful for resolving name conflicts that may occur when using packages. Such a scenario may arise if you import two packages that define classes with the same identifier. For example, consider the following package, which also has a class named SampleCode.

package langref.samples {
    public class SampleCode {}
}

If you import both classes, you will have a name conflict when referring to the SampleCode class.

import tutorial.samples.SampleCode;
import langref.samples.SampleCode;
var mySample:SampleCode = new SampleCode(); // name conflict

The compiler has no way of knowing which SampleCode class to use. To resolve this conflict, you must use the fully qualified name of each class.

var mySample:tutorial.samples.SampleCode = new tutorial.samples.SampleCode();
var mySample:langref.samples.SampleCode = new langref.samples.SampleCode();

Note: Programmers with a C++ background often confuse the import statement with #include . The #include directive is necessary in C++ because C++ compilers process one file at a time, and will not look in other files for class definitions unless a header file is explicitly included. ActionScript 3.0 has an include directive, but it is not designed to import classes and packages. To import classes or packages in ActionScript 3.0, you must use the import statement and place the source file that contains the package in the class path.