Here, we collect all ActionScript 3 language features that are not present in ECMAScript 3 and document how we are going to simulate them.

General assumptions

We use

• ECMAScript 5 strict mode whenever possible
• ECMAScript 5 API (Object.create() etc.) that we know can be "polyfilled" in IE8 adequately
• a well-known module / dependency mechanism like CommonJS modules or AMD
• no other JavaScript library like jQuery, but "VanillaJS"

AS3 language features missing in ECMAScript 3

For every non-trivial language feature, we should introduce a dedicated child page.

...

• $0, $1, ... are auxiliary variables generated by the compiler, chosen to avoid name-clashes with any other identifiers in scope.
• exp1, exp2, ... (italics) are arbitrary complex ActionScript expressions

Classes

Like most JavaScript frameworks, we simulate classes by a constructor function and its prototype chain.
The ES5 API Object.create(prototype,propertyDescriptors) serves this task very well.
While members are properties of the constructor function prototype, static members are properties of the constructor function itself.
Non-public members are discussed in a dedicated sub-section.

Class structure

The translation pattern is a follows:

public class Foo extends Bar {
  // constructor
  public function Foo(/*constructor parameters*/) {
    // constructor code
  }
  // member declarations
  ...
  // static member declarations
  ...
}

becomes

function Foo(/*constructor parameters*/) {
  // constructor code
}
Object.defineProperties(Foo, {
  ... // rewritten static member declarations
});
Foo.prototype = Object.create(Bar.prototype, {
  constructor: { value: Foo },
  ... // rewritten member declarations
});

The constructor property has to be defined explicitly, as otherwise, a subclass would inherit that property from its superclass, resulting in the subclass having the same constructor as its superclass.

Members and visibility (public, protected, internal, private)

Only public and protected members should be stored as properties of the constructor function / its prototype as-is. For protected members, access rights are checked by the compiler.
For private and internal members, we have to avoid name-clashes. There are different cases:

• Private methods (non-static as well as static ones) and private static fields are declared in a new scope, shared by all class members. Thus, they are visible for every method, but not from outside. Non-static private method calls have to be rewritten to run with the correct this.
• Private non-static fields and internal members are renamed: they are post-fixed by $ plus the inheritance level of the declaring class, so that they cannot name-clash with fields of the same name, declared in a subclass or superclass. The inheritance level is a number starting at 0 for Object, continuing with 1 for each direct subclass of Object, then 2 for classes inheriting from these classes, and so on. So for example a private field foo in a class extending Object would be renamed to foo$1. Internal members are also renamed, because they could name-clash with members of the same name, declared in a subclass or superclass residing in another package.

Packages

In ActionScript, packages do not exist at run-time, instead they lead to class and interface declarations having a fully qualified name to avoid name clashes.
To make a JavaScript expression referencing a fully qualified class resemble the ActionScript syntax, packages are often simulated by nested JavaScript objects, for example a class org.apache.flex.test.Foo would be assigned to a package object and then be used like so:

if (!org) org = {};
if (!org.apache) org.apache = {};
if (!org.apache.flex) org.apache.flex = {};
if (!org.apache.flex.test) org.apache.flex.test = {};
org.apache.flex.test.Foo = Foo;

var foo = new org.apache.flex.test.Foo();

(Of course, the code to create a nested package would be moved to a helper function.)
Looking at how classes are usually used in ActionScript, it turns out that they have to be imported (in contrast to Java, even if they are used by their fully-qualified names in the code!) and are only used by their fully-qualified names in the rare case of local name clashes.
Also, nested object access to fully qualified identifiers is not very efficient.
In JavaScript, there is a better solution to accessing namespaced identifiers, namely modules. There are essentially two types of module definitions: synchronous (CommonJS-style) versus asynchronous module definitions / require-calls. While synchronous requires come from the server world (e.g. NodeJS), asynchronous requires better fit realities of module loading in the browser.
When a module with a fully qualified name / path is required (loaded), it can be assigned to a local variable or a callback parameter, so that there is no need to use the fully qualified name.
Only when "exporting" ActionScript classes or other identifiers for direct use from JavaScript, it may make sense to apply the pattern "packages as global nested objects".

So the current suggestion for packages is to define a class that is inside a package as a module with the fully qualified name of that class.

Consider this class

org/apache/flex/test/Foo.as:

package org.apache.flex.test {
public class Foo {
  ...
}
}

and another class in another package using it:

org/apache/flex/test2/Baz.as:

package org.apache.flex.test2 {
import org.apache.flex.test.Foo;
public class Baz {
  ... // use Foo...
}
}

In JavaScript AMD notation, these classes would look like so:

org/apache/flex/test/Foo.js:

define("org/apache/flex/test/Foo", function() {
  function Foo() { ... }
  ...
  return Foo;
});

org/apache/flex/test2/Baz.js:

define("org/apache/flex/test2/Baz", ["org/apache/flex/test/Foo"], function(Foo) {
  function Baz() { ... }
  ... // use Foo...
  return Baz;
});

The first argument to define can be left out when the definition is the only one contained in the file, then the module name is derived from the file name.

To implement another AS3 language feature, namely lazy class creation, the module return value will actually look different (see next section).

Static code execution / lazy class creation

In ActionScript, a class may not only contain static members, but also static code. Static fields may also have initializers which are quite similar to static code.
Static code and static initializers are executed exactly once when the class is created. A class is created right before code that references it is executed. Note that this has nothing to do with import directives, nor does a class trigger immediate initialization of all classes to which it has static dependencies.

No matter how class creation is triggered, it is always executed as a whole:

1. first, its superclass is created (which creates its superclass transitively)
2. then, all static initializers are evaluated, in the order in which they appear in the source code
3. last, all static code statements are executed, in the order in which they appear in the source code

For our implementation, we have to take into account that in a browser, code loading cannot be done synchronously "on demand". Thus we use AMD to resolve all static dependencies and load the code of all classes that are potentially needed at runtime, but create those classes only right before they are actually used.
This changes what our AMD modules return: Instead of the class / constructor function, the return value is a class definition that still has to be initialized to create the actual class.

A class definition is a factory object for a class. A trick for an efficient implementation of the factory method is to use a get property that, upon its first invocation, can be replaced by a simple field with a direct reference to the (now initialized) class. For the sake of brevity and readability (we want the reader to mainly ignore this helper property), let's call that property _ (underscore).

Using this approach, a reference to another class like

import com.acme.OtherClass;

public class ThisClass {
  public function ThisClass() {
    OtherClass.doSomething();
  }
  ...
}

would in generated JavaScript become

define(["com/acme/OtherClass"], function(OtherClass_) {
  return Object.defineProperty({}, "_", {
    configurable: true,
    get: function() {
      function ThisClass() {
        OtherClass_._.doSomething();
      }
      Object.defineProperty(this, "_", { value: ThisClass });
      ...
      return ThisClass;
    }
  });
});

Note how the definition of ThisClass, instead of directly returning its constructor function, returns an object with a get property _, and how its implementation replaces that property by a read-only reference to the constructor (that's why it has to be configurable).
Also note that we use OtherClass_ (postfixed by an underscore!) to be able to use the original name OtherClass for a local variable as a shortcut to the class when we know it has already been initialized, like so:

define(["com/acme/OtherClass"], function(OtherClass_) {
  return Object.defineProperty({}, "_", {
    configurable: true,
    get: function() {
      var OtherClass;
      function ThisClass() {
        (OtherClass = OtherClass_._).doSomething();
        OtherClass.doSomethingElse();
        var x = OtherClass.CONSTANT;
        ...
      }
      Object.defineProperty(this, "_", { value: ThisClass });
      ...
      return ThisClass;
    }
  });
});

Since for the time being, we still target Internet Explorer 8 (or even 7), we need a solution that also works without get properties.
In order not to always need to perform a function call (which results in a runtime penalty and is distracting during debugging), we try to read the field first and only call the factory function in case the property is not yet defined. Following the general pattern of naming explicit get functions (see below), the factory function for IE8 would be called get$_, resulting in the following expression to access a potentially not-yet-created class: (OtherClass_._ || OtherClass_.get$_())

...

Compilation Units

An ActionScript application consists of several compilation units, where one is selected as the application's entry point. A compilation unit is defined in one ActionScript source file, containing a primary declaration and optionally static code. Compilation units are organized in packages.

Types of Compilation Units

Primary declarations can be of the following types:

• class – the most common case is that a source file defines one (externally visible) class.
• interface – in ActionScript, a compilation unit defining an interface may not contain any executable code, so this is a special case handled in section "Interfaces and as/is operator".
• function – for example in the Flash API, there are several functions defined in their own compilation unit. While this feature is less known, it is possible to define your custom package-scope functions.
• var or const – Even variables or constants can be declared outside a class in their own compilation unit.

Property (get/set function) do not seem to be supported as compilation units.

Static code

Any ActionScript code in a compilation unit that is not part of a class member declaration belongs to this compilation unit's static code.
Static fields may also have initializers which are quite similar to static code.
Static code and static initializers of a compilation unit are executed exactly once, the first time code accesses its primary declaration. Note that this has nothing to do with import directives, nor does a compilation unit trigger immediate initialization of all compilation units to which it has static dependencies.

No matter how compilation unit initialization is triggered, it is always executed as a whole:

1. first, its superclass is created (which creates its superclass transitively)
2. then, all static initializers are evaluated, in the order in which they appear in the source code
3. last, all static code statements are executed, in the order in which they appear in the source code

Note that 1. and 2. only apply to compilation units whose primary declaration is a class.

Implementation Solution

For our implementation, we have to take into account that in a browser, code loading cannot be done synchronously "on demand". Thus we use AMD and map compilation units to AMD modules. The AMD loader resolves all static dependencies and loads the code of all compilation units that are potentially needed at runtime. We have to take care of initializing those compilation units only when they are actually used. This determines the value of a compilation unit the corresponding AMD module returns: Instead of the primary declaration itself, the return value is a compilation unit object from which you can retrieve the primary declaration. The trick is that the compilation unit self-initializes when the primary declaration is first requested!

We could implement the primary declaration request by a method of the compilation unit object. But this would involve a function call for each retrieval of the primary declaration, even if the compilation has already been initialized. A trick for an efficient implementation is to use a get property that, upon its first invocation, initializes the compilation unit and replaces itself by a simple field with a direct reference to the primary declaration. For the sake of brevity and readability (we want the reader to mainly ignore this helper property), let's call that property _ (underscore).

Example

Here is a compilation unit with an ActionScript class with a reference to another class:

compilation unit com/acme/ThisClass.as:

package com.acme {
import com.acme.OtherClass;

public class ThisClass {
  public function ThisClass() {
    OtherClass.doSomething();
  }
  ...
}

trace("ThisClass is being initialized...");

}

would in generated JavaScript become

define("com/acme/ThisClass", ["com/acme/OtherClass"], function(OtherClass) {
  return Object.defineProperty({}, "_", {
    configurable: true, // so we can replace it later!
    get: function() {
      function ThisClass() {
        OtherClass._.doSomething();
      }
      // replace "_" by simple property, returning the class:
      Object.defineProperty(this, "_", { value: ThisClass });
      ...
      trace("ThisClass is being initialized...");
      return ThisClass;
    }
  });
});

The first argument to define can be left out when the definition is the only one contained in the file, then the module name is derived from the file name.

Note how the definition of ThisClass, instead of directly returning its constructor function, returns an object with a get property _, and how its implementation replaces that property by a read-only reference to the constructor (that's why it has to be configurable first).
Also note that we use OtherClass as a reference to the compilation unit containing OtherClass as its primary declaration, and so have to rewrite normal access to the class by OtherClass._.

Non-ES5 Browser Issues

Since for the time being, we still target Internet Explorer 8 (or even 7), we need a solution that also works without get properties, so we need a more sophisticated solution for the _ property.
In order not to always need to perform a function call (which results in a runtime penalty and is distracting during debugging), we try to read the field first and only call the function in case the property is not yet defined. Following the general pattern of naming explicit get functions (see below), the factory function for IE8 would be called _$get, resulting in the following expression to access a class from potentially not-yet-initialized compilation unit: (OtherClass_._ || OtherClass_._$get())

Packages

In ActionScript, packages do not exist at run-time, instead they lead to primary declarations having a fully qualified name to avoid name clashes of global identifiers.
Mapping compilation units to AMD modules, it is straight-forward to define a primary declaration that is inside a package as a module with the fully qualified name of that class. AMD modules usually use nested directories and thus slashes ("/") instead of dots.

Looking at how classes are usually used in ActionScript, it turns out that they have to be imported (in contrast to Java, even if they are used by their fully-qualified names in the code!) and are only used by their fully-qualified names in the rare case of local name clashes.
When a module with a fully qualified name / path is required (loaded), it is assigned to a callback parameter, so that there is no need to use the fully qualified name. Only on name-clashes between un-qualified names, the parameter has to be renamed, for example by using the fully-qualified names with "." replaced by "$".

Conclusion

Granted, simulating compilation units and exact static code execution makes the solution a bit more complex, but it is an important AS3 language feature, and using the property access trick makes the implementation quite efficient, at least in modern browsers. In many cases, creating classes only when they are actually needed even increases performance, at least application start-up time, but also when many static dependencies are not actually needed at runtime at all.

Classes

Like most JavaScript frameworks, we simulate classes by a constructor function and its prototype chain.
The ES5 API Object.create(prototype,propertyDescriptors) serves this task very well.
While members are properties of the constructor function prototype, static members are properties of the constructor function itself.
Non-public members are discussed in a dedicated sub-section.

Class structure

The translation pattern is a follows:

public class Foo extends Bar {
  // constructor
  public function Foo(/*constructor parameters*/) {
    // constructor code
  }
  // member declarations
  ...
  // static member declarations
  ...
}

becomes

function Foo(/*constructor parameters*/) {
  // constructor code
}
Object.defineProperties(Foo, {
  ... // rewritten static member declarations
});
Foo.prototype = Object.create(Bar.prototype, {
  constructor: { value: Foo },
  ... // rewritten member declarations
});

The constructor property has to be defined explicitly, as otherwise, a subclass would inherit that property from its superclass, resulting in the subclass having the same constructor as its superclass.

Members and visibility (public, protected, internal, private)

Only public and protected members should be stored as properties of the constructor function / its prototype as-is. For protected members, access rights are checked by the compiler.
For private and internal members, we have to avoid name-clashes. There are different cases:

• Private methods (non-static as well as static ones) and private static fields are declared in a new scope, shared by all class members. Thus, they are visible for every method, but not from outside. Non-static private method calls have to be rewritten to run with the correct this.
• Private non-static fields and internal members are renamed: they are post-fixed by $ plus the inheritance level of the declaring class, so that they cannot name-clash with fields of the same name, declared in a subclass or superclass. The inheritance level is a number starting at 0 for Object, continuing with 1 for each direct subclass of Object, then 2 for classes inheriting from these classes, and so on. So for example a private field foo in a class extending Object would be renamed to foo$1. Internal members are also renamed, because they could name-clash with members of the same name, declared in a subclass or superclass residing in another package.

Interfaces plus "is" and "as" operator

In ActionScript, interfaces are mainly used by the compiler for type checking. However, type checks can also be performed at runtime, using the AS3 operators instanceof, is, and as. instanceof only works for classes and automatically has the correct semantics when simulating classes via the prototype chain, so it can be used as-is in JavaScript.
x as T is simply defined as x is T ? x : null and would be implemented as a runtime helper function.
So the only operator we really have to simulate is is. To do so, we need some information about interfaces:

...

function is(object, type) {
  return !!type && object !== undefined && object !== null &&
         (object instanceof type ||
          typeof type.isInstance === "function" && type.isInstance(object));
}

Parameter default values

TODO

Rest (...) parameter

TODO

Bound methods

TODO

"this" is always in scope

TODO

Statements

TODO

for each

TODO

Operators

TODO

&&=

TODO

||=

TODO