Tutorials, extensions, and source files for ActionScript, Flash, and other Adobe products.


Implicit Imports, XMLParser, and Failure in Flash

Posted November 01, 2009 by senocular

Have you ever noticed that you don't have to import any of the native flash classes when writing timeline code in Flash Professional? This is because they're automatically imported for you in an effort to simply basic timeline code usage. These imports are even outlined in a file called "implicitImports.xml" within Flash's configuration directory for ActionScript 3.0. Lets take a look at its contents:
<implicitImport name = "adobe.utils.*"/>
<implicitImport name = "flash.accessibility.*"/>
<implicitImport name = "flash.data.*" swfVersion = "0" airVersion = "1.0"/>
<implicitImport name = "flash.desktop.*" swfVersion = "10" airVersion = "1.0"/>
<implicitImport name = "flash.display.*"/>
<implicitImport name = "flash.errors.*"/>
<implicitImport name = "flash.events.*"/>
<implicitImport name = "flash.external.*"/>
<implicitImport name = "flash.filesystem.*" swfVersion = "0" airVersion = "1.0"/>
<implicitImport name = "flash.filters.*"/>
<implicitImport name = "flash.geom.*"/>
<implicitImport name = "flash.html.*" swfVersion = "0" airVersion = "1.0"/>
<implicitImport name = "flash.media.*"/>
<implicitImport name = "flash.net.*"/>
<implicitImport name = "flash.printing.*"/>
<implicitImport name = "flash.profiler.*"/>
<implicitImport name = "flash.sampler.*" airVersion = "1.5"/>
<implicitImport name = "flash.security.*" swfVersion = "0" airVersion = "1.0"/>
<implicitImport name = "flash.system.*"/>
<implicitImport name = "flash.text.*"/>
<implicitImport name = "flash.text.engine.*" swfVersion = "10" airVersion = "0"/>
<implicitImport name = "flash.ui.*"/>
<implicitImport name = "flash.utils.*"/>
<implicitImport name = "flash.xml.*"/>

What you see is a bunch of import paths along with some version information indicating when they should be used. Pretty basic stuff, and useful for the novice programmer (and the lazy ones too).

You may notice that each of these imports use the wildcard (*) to import all classes within their respective packages. This makes everything immediately accessible. Good thing, right?

Yes and no. Yes, it's good in that every class is available, but no in that every class is available. Why is that bad? Because it can create naming conflicts, and unexpected ones at that.

The case at hand: XMLParser. What is XMLParser? It's a class - a custom class that I, or you, or anyone has written to parse XML, as its name appropriately suggests. To use this class, you import it and create an instance of it. Try it out in Flash, then test... FAIL. What's this? Flash can't find your class?

1046: Type was not found or was not a compile-time constant: XMLParser.
1180: Call to a possibly undefined method XMLParser.

Turns out there's a naming conflict. The class can, in fact, be found, but what the error isn't indicating is that the class already exists. You may be asking yourself what class, since after all, you've written no other XMLParser classes and there aren't any documented for Flash. But therein lies the catch. There is an XMLParser class in Flash, one internal to the flash.xml package (internal use only), and one automatically included in with the implicit imports.

Solutions? One is simply don't name your class XMLParser. If that's not an option, you'll have to use the fully qualified name to type and define your class, or define a custom class for your timeline object at which point implicit imports aren't used.