With your handy dandy object-oriented skills, you know that it’s always wise to separate the implementation from its structure, allowing for flexibility. Having disabled automatic stage instance declarations, you have to declare the reference yourself; otherwise, when you compile your code, a ReferenceError occurs:
ReferenceError: Error #1056: Cannot create property inner_mc on TestClip. at flash.display::Sprite/constructChildren()
at flash.display::Sprite() at flash.display::MovieClip() at TestClip()
at DocumentClass()
To add a variable representing the nested clip, open the TestClip class and add private var inner_mc. But you find that again, at compile time, you’re confronted with a ReferenceError. Unless you specifically declare inner_mc as a public variable, you continue to face the same ReferenceError. Why? This has to do with the order in which things are compiled and the hashtable used by MovieClips that enabled the clips to be added. Because MovieClips let you add dynamic properties, its references must remain public. By extending the MovieClip class to allow TestClip to be defined, the hashtable is removed unless you specify dynamic behavior for TestClip as well. This allows the nested clip to be accepted after your classes are compiled. If you were to define your clip as dynamic, you could get away with defining inner_mc as private. Again you’ve broken the concept of encapsulation, because you’re allowing dynamic behavior on the class. This is exactly what would occur if you declared TestClip as a sealed class and used it as the
Now, when you compile the clip, because you’ve defined private var inner_mc in the class TestClip, the compiler no longer throws a reference error. The reason is apparent when you use the describeType method from the flash.utils package. This method reveals the details of the parameterized object instance, in the form of XML: trace( describeType( new SpecificallyGivenName() ) )
// <type name=" SpecificallyGivenName " base="TestClip" isDynamic="true" isFinal="false" isStatic="false"> ...
When the Flash compiler can’t find a class labeled SpecificallyGivenName, it supplies one at the time of
compilation; and to fulfill its role, SpecificallyGivenName is defined as being dynamic. This leaves you with the solution of defining your references as being public, so you can continue to seal your class to further maintain data hiding.
Application Domain
The application domain, not to be confused with problem domain, represents the memory location of an application’s given definitions. When a .swf file is published, the compiler bundles all application definitions into that of an application domain. If a .swf is loaded into another .swf, the definitions of both .swfs remain partitioned from one another. This ensures that the definitions of one application don’t interfere with the naming conventions of possibly same named definitions between the two .swf files.
You instantiate an ApplicationDomain by importing the flash.system.ApplicationDomain class. The ApplicationDomain class, when instantiated, accepts as an optional parameter a reference to a preexisting applicationDomain. Specifying a preexisting applicationDomain lets the devised partition use definitions from the passed-in applicationDomain (appDom for short).
Two important properties of the ApplicationDomain class are currentDomain and parentDomain. currentDomain is a static property that points to the applicationDomain, which holds the code currently being executed. parentDomain is a pointer to the parent’s ApplicationDomain, providing one exists.
By default, when a .swf file is published, its applicationDomain doesn’t have a parentDomain, and all definitions are considered to be stored in what is referred to as a systemDomain. This is where built-in definitions of the ActionScript 3 language are contained (MovieClip, Sprite, Loader, and so on). The packaged definitions are partitioned onto that of the systemDomain, allowing all user-defined code to refer to the built-in definitions. Only when a .swf file is loaded into another .swf is a parentDomain possibly available. Possibly, because a parentDomain is available only when an instantiation of an ApplicationDomain includes a reference to an existing applicationDomain,
When you load one .swf file into another, you can modify the partitioning of the loading .swf’s definitions by specifying one of the following four application domain settings:
Child of the loader’s
• ApplicationDomain: The default setting when loading a .swf file, applied using new ApplicationDomain(ApplicationDomain.currentDomain). This line of code creates the new application domain on the loading .swf, but with a relationship to the application domain of the parent container. Attaching the ApplicationDomain on the parent’s appDom allows the loaded .swf file to use the parent’s definitions by referring to them as if they were located in the loaded .swf file’s ApplicationDomain.currentDomain.
Loader’s
• ApplicationDomain: Specified as ApplicationDomain.currentDomain. No partition is created, allowing all definitions of the child to be loaded into the loader’s appDom. This is, of course, with the exception of duplicate definitions, which are disregarded.
Child of the system
• ApplicationDomain: Specified as new ApplicationDomain( null ). Creates a partition among the child and parent definitions. This ensures that definitions of similar names don’t interfere with one another. It also ensures that the definitions of the two .swfs aren’t visible to one another, thus isolating definitions between the two.
Child of a specified
• ApplicationDomain: Specified as ApplicationDomain( 'application_ domain_here' ). When you specify the relationship between a loading .swf file’s definitions and another, you can partition the ApplicationDomain among the child’s appDom with the visibility of another appDom’s definitions. You can do so via the parentDomain property or through a reference to an appDom.
You can use the specification among ApplicationDomains only when loading .swf files published for the ActionScript 3 language. To specify the ApplicationDomain settings, a property on the LoaderContext object must reflect such changes, as you’ll see next.