The tasks of the InterfaceCompiler are:
1. Expose the public signature of our generated MXML class at the same point in the compiler workflow as a native AS class would. This means generating "public signature" AS code immediately (i.e., for consumption in analyze1..N). This public signature must contain:
-typed declarations for any MXML children with id attributes;
-user script code (which might also contain public declarations).
2. "Bring in" all types referred to by component tags, so that MXML DOM traversal, which happens in the ImplementationCompiler, has the information it needs to disambiguate child tags.
Example: if a <Button/> tag appears in the document, information contained in the definition for mx.controls.Button (assuming that's what <Button/> resolves to) will be necessary for disambiguating properties, styles, nested components, etc., in the associated MXML subtree.
The InterfaceCompiler's postprocess() phase uses (local class) DependencyAnalyzer to do this type registration.
Note that not all necessary imports are registered here, only types needed to process the MXML DOM. For instance, the definitions specified by name for Class- and Function-typed properties and styles need to be imported, but they are not necessary for DOM processing. They're registered as imports later, during DOM processing, as the properties etc. are actually processed (see e.g. AbstractBuilder.TextParser's className() handler).
Why not register all such types here? Because values are subject to interpretation (e.g. @Embeds, or {bindings}, may appear as rvalues, and have different type implications), and all that sort of interpretation happens during DOM processing (by the Builders). Ordinary type registration happens naturally at that point; think of the registration that happens here as being "early" out of necessity, but as minimal as possible.
2a. update: the blanket early-class-import requirement due to style trimming has been removed. However, there are still early-import dependencies in the Builders (other than for DOM-walking), including some that may be unnecessary. One that definitely *is* and will remain necessary is due to generating classname-to-IFactory coercions: the AbstractBuilder code introspects the definition associated with the classname in order to generate automatic assignments of properties like outerDocument. Others may be brunable, including event type defs and generic imports of the classes assigned to Class-typed properties. TODO: review and narrow the set of import requests generated here to only those that are strictly necessary.
At the end of the InterfaceCompiler phases, the workflow switches to ImplementationCompiler for generation of the complete AS code. (As noted above, the additional dependencies outside those needed purely for the document's component tags, are detected and registered during that phase.)
@author Clement WongChanged to extend AbstractSubCompiler to clean up benchmarking code and enble embedded compiler benchmarking - bfrazer Changed class to public so that it can be used directly for mxml parsing by other tools. - gauravj