MXMLExtrema

MXMLC as part of MXMLExtrema provides an enhanced compiler infrastructure for the languages ActionScript 3 and MXML and the CSS3 subset present in Adobe Flex.

Dependencies

MXMLExtrema depends in the Rust systems language.

Internals: Source cycle

The MXML compiler handles three source formats simultaneously: ActionScript 3, MXML and CSS.

First pass

1. For all ActionScript 3 sources, enumerate every package definition into an immutable sequence = allPackages.
2. For each definition in allPackages, declare the respective ActionScript 3 package.
3. For each MXML source, declare the respective ActionScript 3 package.

Resolution passes

1. Let remPackages be a mutable clone of the allPackages sequence.
2. Let remAS be a mutable sequence containing all ActionScript 3 sources.
3. Let remMXML be a mutable sequence containing all MXML sources.
4. Let remCSS be an empty sequence.
5. While remPackages is non empty or remMXML is non empty
   1. Visit directives across remPackages or defer otherwise.
      1. Remove each element from remPackages that is of the VerifierPhase::Finished phase.
   2. Visit element in remMXML or defer otherwise.
      1. Remove each element from remMXML that is of the VerifierPhase::Finished phase.
6. For each package in allPackages
   1. Visit statements
7. While remAS is non empty
   1. Resolve directives and then statements for each remAS
   2. Remove each element from remAS that has been finished.
8. While remCSS is non empty
   1. Visit directives for each remCSS element or defer
   2. Remove each element from remCSS that has been finished.
9. Visit each deferred function expression or defer for a number of MAX_CYCLES.
10. Add verify error for each function expression that could not be resolved.
11. Finish each definition conflict, reporting any errors.
12. Reset verifier state.

MXML source cycle

MXML sources go through compiler phases asynchronously.

Every MXML component belongs to an ActionScript 3 package, which is determined according to the source path matching its path.

• For example, given that the set of source paths is (src/) and the MXML component is src/com/expert/ui/StatusBar.mxml, the MXML component belongs to the com.expert.ui package.

CSS source cycle

CSS sources are included either from a MXML component or from a chief.skins.Theme subclass.

CSS sources go through compiler phases asynchronously, although they do not considerably influence the ActionScript 3 semantic data.

ActionScript 3 source cycle

ActionScript 3 sources go through compiler phases asynchronously.

Source specification

Sources are specified by recursive directories referred to as source paths. A source path is not taken as a source unless the respective MXMLShare manifest source element sets include to true.

Include directive

ActionScript files that are loaded from an include directive must always contain an .include.as extension.

The following is an example ActionScript 3 program demonstrating the case:

// src/bath.as
package
{
    public function bath():void
    {
        include "./bathLog.include.as";
    }
}

// src/bathLog.include.as
trace("taking a bath");

External mode

Verification may occur in the external mode, where all methods must be either abstract or native and action statements and static media embedding are not allowed. In the external mode, no bytecode or SWF symbols are generated.

Adobe AIR

The external mode is used primarily for the Adobe AIR built-ins (top-level, flash.** and air.**). The top-level includes the parameterized Vector.<T> for instance.

The Flex library (chief.**) is not external but part of the compiler, therefore it is not verified in external mode.

Embedding

There are several ways of embedding static media in ActionScript 3 programs. Both ActionScript 3, MXML and CSS have a way of embedding static media.

• ActionScript 3 uses the [Embed] meta data either in classes or variables.
• CSS uses the Embed() function.
• CSS uses @font-face statements that embed a local or system font.

Embed meta-data

The [Embed] ActionScript 3 meta-data is used in two different ways.

It may appear in a class definition:

package
{
    import flash.utils.*;

    [Embed(...)]
    public class CustomFont extends ByteArray
    {
    }
}

It may appear in a variable definition:

package
{
    public class StaticFonts
    {
        [Embed(...)]
        public static const custom:Class;
    }
}

Artifacts

MXMLC provides two artifacts: an ABC bytecode and a SWF file.

ABC artifact

The logical code of all ActionScript 3, MXML and CSS sources are together contributed to a ActionScript Virtual Machine 2 Bytecode (ABC) format, which is then contributed to the artifact SWF file.

SWF artifact

MXMLC compiles all sources together into a Shockwave Flash File (SWF), to which are contributed for example ActionScript Virtual Machine 2 Bytecode (ABC), binaries and font definitions (as part of embedding fonts).

User interface

MXMLC ships with the Chief framework which supports building user interfaces and layouts with little effort.

Creating a theme

The Chief framework supports linking a cascading style sheet file against a class that extends chief.skins.Theme.

package
{
    import chief.skins.*;

    [Stylesheet(source="style.css")]
    public class RockTheme extends Theme
    {
    }
}

Variables

The PropertyReference(name) CSS calls resolve to a property within the chief.skins.Theme subclass scope, whether it is a static property or an instance property.

Data binding

Syntax

MXML attributes identifying Bindable properties may contain an interpolated braces group containing an ActionScript 3 expression that is either a string literal or a member expression.

• When that braces group contains a string literal, it behaves as an escaped string that may contain braces.
• When that braces group contains a member expression, the compiler resolves that expression to a Bindable property and listens to the respective PropertyChangeEvent event, always computing the property on change.

Bindable meta-data

The [Bindable] ActionScript 3 meta-data is used to indicate that either a property or all properties of a class trigger a PropertyChangeEvent after write. The event is only dispatched if newValue !== prevValue (notice the strict !== operator).

The [Bindable] meta-data may be in one of the forms:

[Bindable]
[Bindable("eventName")]
[Bindable(event="eventName")]

If the event name is omitted, it defaults to "propertyChange".

A setter may contain the [Bindable] meta-data, behaving similiarly as above, indicating that the parent virtual slot contains a specific Bindable event name.

To support [Bindable], the bytecode generator generates event dispatch code right after the property's assignment, whether within a destructuring assignment that affects the enclosing class's instance or a direct assignment.

Events

Event meta-data

The [Event] meta-data is used to indicate an event that is likely dispatched in a class or interface.

It may define the following properties:

• name="eventName" - Specifies the event type string.
• type="XEvent" - Specifies the class that represents the event object.
• bubbles="true|false" - Specifies whether the event is dispatched in the bubbling phase or not.

It may contain an ASDoc comment containing the following tags:

• @eventType XEvent.Y - Specifies a class static constant identifying the event as a string.
• @eventType String - Indicates that the event may be identified by any string.