9.2 Defining Packages

Defining a package for a class requires two general steps:

1. Create a directory structure whose name identically matches the package hierarchy.

2. Specify the package name when defining the class.

Note that there is no such thing as a package file, per se. A package is a concept based on placing a given class's .as file in the appropriate folder.

For example, to place the class Player in the package com.yourdomain.game , we'd follow these steps:

1. Create a new directory named com .

2. Create a new directory inside com named yourdomain .

3. Create a new directory inside yourdomain named game .

4. Create a text file, Player.as , in the directory /com/yourdomain/game/ .

5. In Player.as , add the following code:

    class com.yourdomain.game.Player {   // Class body not shown... } 

   
   

The class declaration must use the fully qualified class name, in this case com.yourdomain.game.Player , indicating to the compiler that the package for the Player class is com.yourdomain.game .

If any part of the package or class name does not match the actual names of the system directories and .as file, the compiler generates an error (case sensitivity matters!). For example, if the letter "e" were missing in the word "game" in our class definition:

 // Oops! Missing the "e" in "game"! class com.yourdomain.gam.Player {   // Class body not shown... } 

the compiler would generate the error:

 The class 'com.yourdomain.gam.Player' needs to be defined in a  file whose relative path is 'com\yourdomain\gam\Player.as'. 

In our generic game example, we put all the game- related classes in a package named game . We might also define a subpackage named vehicle to hold the classes that implement all the vehicles, including SpaceShip and its subclasses (perhaps Fighter , Bomber , and Cruiser ). Furthermore, the SpaceShip class might have a superclass named Vehicle that also resides in the vehicles package. It's not uncommon for a package and a class to have the same name (except the package name is lowercase and the class name is uppercase). For example, in Chapter 17, we'll create a class named Logger and place it in a package named logger . The fully qualified class reference is:

 logger.Logger 

Here, we can see the capitalization conventions for packages and classes really pay off. At a glance, we know that logger is the package because it starts with a lowercase "l" and that Logger is the class because it starts with a capital "L."

Note that the package path for our example SpaceShip class is:

 game.vehicles.SpaceShip 

not

 game.vehicles.Vehicle.SpaceShip 

That is, don't attempt to include the superclass name in the fully qualified name for a subclass. A package names tells the compiler where to find the subclass's .as file and has no bearing on the subclass's inheritance relationship to the superclass (which is established via extends ).