Including imports

Do you remember the #include "filename.as" AS2 directive? It was often used to include predefined prototype functions in AS2. Since using prototypes become obsolete in AS3 (in favour of the inheritance) the include in often underused.

For example, Darron Shall suggests using include directive to mimic multiple inheritance. Recently, I had been given a glimpse of brain damage enlightenment and I started using it again in AS3 for including all project specific libs only. If you want to pass me the hammer now, please read on.

How?

Using wildcards (like import flash.display.*) is often considered a bad practice (or laziness) as we don't know what classes/packages are actually being imported. So we are left with typing all import directives for every class we write. Very commonly we use the same shared functionality (either a framework or built-in classes) in the SWF. The idea is that instead of having to import the same classes in every project class, we can have a list of them in a file, i.e.:

import flash.display.Bitmap;
import flash.display.MovieClip;
import flash.display.Sprite;
import flash.events.Event;
import flash.events.MouseEvent;
import flash.text.TextField;
import flash.text.TextFieldAutoSize;
import flash.utils.setTimeout;
import gs.TweenLite;

and then stop worrying anymore about what needs to be imported.

All you need to do is to place include "../../imports.as"; where your import directives would normally live. I've personally chosen to put it in the same location as the source directory.

package net.blog2t
{
    include "../../imports.as";

    public class Banner extends Sprite
    {
    }
}

Then you can do it for every project specific class you add.

If you're on OS X and using Textmate, you can use the shortcut – F5 key to sort lines and remove duplicated entries.

06:00 PM | | 2 Comments | Tags: , , ,

Comments

  1. Thanks Jackson, it's nice to hear some good feedback!

    You're (mostly) right, but I only propose this solution when you're coding a single project (small website, banner etc.) that has custom classes that are unlikely to be reused. All those classes will have common imports, so you can chuck them into one file. I use Flash IDE to compile (mainly because it's so easy to create assets) and I found it easy (lazy) to have a single file with all imports. I'd never use it for framework classes or anything that could have it's own life (i.e. GUI components), and I stick to just one includes file.

    1. Could be so, unless you consider the above (project specific) approach.
    2. Sure, but it's up to you what you put into it ;-)
    3. I'd only use one file with imports, otherwise it's a mess.
    4. I think the unused classes won't get imported when not instantiated, it should be true for wildcard importing as well, that's why some people do use it. But if that's true, you may end up having a list of imports of all possible classes – then it's up to the compiler what to actually import – I know, very bad idea.
    5. Possibly will, especially i.e. FDT will try to add all necessary imports for you anyway.

    Just wanted to share this idea anyway.

    Og2t on
  2. Here are some thoughts I had while reading this:

    1. Using an include directive seems to hide the imported classes/functions even more than wildcard importing.
    2. It's not immediately obvious what's in the AS file. It may even have code other than imports.
    3. The includes.as probably doesn't have a good set of includes for every file. So you will probably start to need multiple includes.as copies: includes_tween.as, includes_3d.as, etc.
    4. When includes.as doesn't have what you need, you'll need to import some more. That's not so bad, but then there's probably more in there that you're not needing. This leads to over-including and the similar problems with importing by wildcard.
    5. I haven't checked, but this may break IDEs (FlashDevelop, Flash Builder, FDT, etc.) and their recognition of imported types.
    Jackson Dunstan on

Adding comments disabled for now.