The Blog

Hi again,

It took me more time than I first thought to write this part down, since i’ve been very busy, but here it is.

As I said, I’ll talk about packages in this second part of the OOP tutorial.

So. What is a package?: Is a way of grouping things together and distinguish between things that look-a-like but come from different sources.
For example: we create our class Apple and a team collegue brings his own version of class Apple. This creates ambiguity for the compiler (and for us also) because it can’t decide which version of the Apple class to use. To avoid this ambiguity, without changing the name of any of the classes, we move them into separate packages: let’s say mypackage will hold our Apple class and colleguepackage will hold our collegue’s class.
To refer to the classes inside packages, we can use the name of the package, like this:
mypackage.Apple and colleguepackage.Apple
As you can see the “.” [dot] operator is used to access content inside packages. Remember however that classes declared internal are not accesible outside the package they are contained in!

Let’s see some code:

What we did: we create the package mypackage, and inside it we created the class Apple, public.

To use the class we need to import it:

Every class must be inside a package, but it’s worth noting that a global package exists. The classes inside the global package are available without importing them (still the access specifiers occur). To create a class inside the global package, don’t give any name to the package, like this:

Now the Apple class can be used directly:

Packages can be nested. That means we can have a package named com and inside this package, we can have another package named com.otherpackage. Of course the nesting can go deeper, any package can hold other packages..
How do we create nested packages, as a regular package, only specifying the entire qualified name for that package. Example:
Define the com package that will hold a Test class:

Define the com.otherpackage.mypackage that will hold the Apple class:

Looking at the com.otherpackage.mypackage package we can say:
com.otherpackage.mypackage is a sub-package of com.otherpackage, which is a sub-package of com, which is a sub-package of the global package.

While classes must be situated in it’s own file, with the name of the class being the name of the file, packages must be insde their own directories, the name of the package being the name of the folder.

This being said, for our com.otherpackage.mypackage package, we need the next directory structure:

• com
  • otherpackage
    • mypackage

So if we had the com.Test and com.otherpackage.mypackage.Apple classes, just as we defined them above, we’d have the following directory and files structure:

• com
  • otherpackage
    • mypackage
      • Apple.as
  • Test.as

Ofcourse, putting a class in the global package, we would not create any directory, the file should be placed right on the top folder of the classpath.

I mentioned the classpath, so i think it worth talking a bit about it.
The classpath is nothing else than the path where the flash compiler will look in order to find the classes you use in your project.
The directories of your packages are relative to this classpath.
The default classpath, is the root directory where you have your fla file (that is if you’re using Flash).
But you can change that to fit your needs.

That’s it about this part.
Any comments are welcome!

In the next part we’ll talk about inheritance and more about access specifiers.

admin Actionscript 3.0, Object Oriented Programming as3, oop, package