ECMAScript 4

I have began my practice with ActionScript 3, PHP, JavaScript and other technologies in 2015 and I have been exploring ECMAScript 4 — the inexistent edition of ECMAScript — since 2017 and determined that ECMAScript 4 and ECMAScript Harmony take different pathways.

In one hand, ES4 focuses both in strictness, radicals, and inheritance; in the other hand, ECMAScript Harmony derivatives focus in reactive patterns.

Exploring design

E4X defined a consistent series of constructs for dealing with eXtensible Markup Language.

default xml namespace = fns;

for each (var v in o) {
    //
}

E4X extended the language with reasonable punctuators and slightly specific syntax used for dealing with XML.

o..descendants
;
o.(@x == "y")
;
prefix::localName

ES4 used consistent constructs throughout the language.

Apache Royale

The Apache Royale framework extended ActionScript 3 with certain constructs inspired by ECMAScript Harmony, but still in a different form.

class C1 {
    function default() {}
}

new C1().default()

Whereas, in ECMAScript Harmony, programmers defined properties of a reserved word name using brackets.

Radicals

ES4 had a sound, fixture type system; however, for example, ActionScript 3 has not implemented structural types as proposed in ES4 and for cases where a variable may be of more than one type, the programmer used a base type such as * or Object. Type inference could have been blandly possible in ActionScript 3, however it would not be very common.

Inheritance

The package domain system in ES4 differed from the ES Harmony module system.

The following verifies and evaluates correctly in ES4, but not in ES Harmony:

class C2 extends C1 {}

class C1 {}

TypeScript does not evaluate that correctly either and may not generate any compilation error when used at different modules.

Event model

In AS3 it was common to handle events using human arbitrary constants at classes, such as FooEvent.FOO and representing the event objects as that same class.

Meta-data were used at EventDispatcher subclasses (or IEventDispatcher interfaces) to enumerate the dispatchable events.

package {
    import flash.events.*;
    /**
     * @eventType Q1Event.PLAY
     */
    [Event(name="play", type="Q1Event")]
    /**
     * @eventType Q1Event.STOP
     */
    [Event(name="stop", type="Q1Event")]
    /**
     * Q1 class.
     */
    public class Q1 extends EventDispatcher {}
}

This was important not only for ASDoc purposes, but also for MXML components.

MXML components

In AS3, UI components could be implemented in MXML files and link a subset of Cascading Style Sheets (CSS3).

The MXML compiler (the Flex compiler) was responsible for compiling AS3, MXML, and a CSS3 subset.

That CSS3 subset did not support CSS3 variables; but that CSS3 subset was able to refer to properties in the MXML component through the PropertyReference(...) function.

Data bindings

MXML components were able to use a basic form of data bindings, where AS3 would use the [Bindable] meta-data to automatically dispatch MXML PropertyChangeEvent events for one or more properties right after a direct assignment.

ActionScript 3

ActionScript 3 implemented a subset of the ECMAScript 4th edition. AS3 did not implement, for example, unit pragmas, destructuring, type definitions, triple string literals, function bodies as expressions, and more.

The ECMAScript 4 overview paper for example did not seem to relate meta-data at all, nor did it refer to compilation constants supported in the AS3 MXML compiler.

ECMAScript 4 and ActionScript 3 had a strong relationship, including the fact that ES4 compiler centrals such as Tamarin had a compiler generating AVM2 bytecode or some similiar bytecode.