That statement was describing something different...
Quote:
Although moving the legacy XML class into a package is a good first step, most users of the legacy XML classes will import the flash.xml package, which will generate the same name conflict unless you remember to always use the fully qualified name of the legacy XML class (flash.xml.XML). To avoid this situation, the legacy XML class is now named XMLDocument, as the following example shows:
package flash.xml
{
class XMLDocument {}
class XMLNode {}
class XMLSocket {}
}
|
it's a written out description of the contents in the flash.xml package.
You can have multiple classes inside of one source file, but only 1 can be visible to the outside of that sourceFile. For instance in this scenario I have a package with a visible class called "subClass". In the source file I have another class called "internalClass" that can be created from with in this source file... but ONLY in this source file, that is all.
Code:
package {
public class subClass {
public function subClass() {
trace ("somethingOrOther");
var a:internalClass = new internalClass();
}
}
}
class internalClass {
public function internalClass() {
trace("another class");
}
}
So if in my main class document for my project I create an instance of subClass like so:
Code:
package {
import flash.display.Sprite;
public class main extends Sprite {
public function main():void {
var test:subClass = new subClass();
}
}
}
the output traces:
Quote:
somethingOrOther
another class
|
...
As for the package system. It's a way to manage large numbers of source files that have relations to each other. The package name refers to the directory it exists in, with in the directory with all its different classes (in their own .as files) you can define a class to be public to the entire library (by denoting the class public), or only public to classes that exist inside its own package (internal class). This way if you have a class that depends on and should only be created by another class in the package you make it internal; this way when utilizing the library you don't go and create a class that can't be managed outside of its package.
For instance, in the APE physics engine there is the class "CollisionDetector". This class has no use to anyone on its own and is ONLY used by the APEngine itself. With out the APEngine this class wouldn't function... so it remains internal and only used by the APEngine class.
...
more interestingly if we go back to the initial part of this post. You can create the visible class like before... and then a bunch of classes that are only inside of this source file. Then upon cronstruction of the instance you pass a parameter in that denotes what kind of class it is of the marriad of classes with in it...
kinda weird and I've yet to find a use for it personally... but neat none the less. Check here all the way at the bottom of the page:
http://livedocs.adobe.com/flash/9.0/...fV3/Class.html
packages vs directories?
Linear Mode
