Language ~ Limitations on ActionScript 3

Limitations on ActionScript 3

Most, but not yet all language features of ActionScript 3 have been implemented. The implemented features behave almost exactly as in ActionScript 3, but there are a few remaining gotchas or limitations. It is planned to remove limitations with every new Jangaroo release.

• Each input file for the compiler must contain exactly one public class in one package declaration. It is not permitted to define a class without a package (but you can use the top-level package). Defining package-scope functions is not supported. However, Jangaroo now supports same-file helper classes, i.e. classes that can only be used within the same file.
• When a function overrides a function defined in the super class, the compiler does not check whether the override keyword is present. Vice versa, the override keyword may be present even when the function does not override. However, these checks are performed at runtime and result in a runtime Error. Moreover, IDEs do perform these checks during source code editing and issue a warning.
• The modifiers protected and internal, as well as any custom namespaces, are accepted by the compiler, but semantically ignored (treated as public).

Bound Methods

In JavaScript, when writing b=o.m where m is a method defined in the class of o, the result is only the function m, not the method m bound to the object o. When you execute b(), the variable this will not be set to o as specified for ActionScript 3. The same holds true if b is a parameter assigned by a function call. A typical pattern where this occurs is handing in a callback function as a parameter.

Jangaroo supports the ActionScript 3 semantics, but only for methods of the same object:

If the compiler detects an expression equivalent to this.m (i.e. explicit or implicit usage of this.) where m is a method (function), and no invocation is done (not followed by parentheses), you do not have to care about anything. The expression evaluates to a method bound to the current object (this), so it can safely be assigned to a local variable or used as a parameter value, just like in AS3. The bound method is only constructed on the first call and stored in the object. Any subsequent call with the same parameters returns the identical function object. This is important e.g. when removing event listeners, and also improves performance.

We are planning to extend this to all typed expressions. Until then, for the rare case of accessing methods of other objects without invoking them directly, you have to define a helper function that delegates to the other object's method, e.g. instead of

function addEventListener(l:Listener):void {  
  this.peer.onReceive(l.receive);  
}

you have to write

function addEventListener(l:Listener):void {  
  this.peer.onReceive(function():* {  
    return l.receive.apply(l, arguments);  
  });  
}

Note that when you want to remove this event listener, you have to keep a reference to the anonymous helper function, for instance by adding it to object l.

Type Casts

ActionScript features two different syntax constructs for type casts:

• type ( expr ) -- the older syntax looks exactly like a function call and throws a TypeError if the expression cannot be converted to the required type.
• expr as type -- the new syntax can easily be told apart from a function call and returns null if the expression is not of the required type. No conversion whatsoever is performed.

Since old-style type casts look like function calls, Jangaroo and Adobe strongly recommend using the new syntax.

To resemble AS3 semantics, the Jangaroo compiler converts an as-expression into a type check, returning null if the expression is not of the given type (expr is type ? expr : null).

Since there are certain usages of old-style type casts in ActionScript 3 which actually transform the expression value, the compiler keeps these as function calls for certain built-in top-level identifiers (Number, String, Boolean, int, uint, Date, Array, RegExp), but drops them (generates comments) for all other types. Thus, the generated code deviates from AS3 semantics, as it never throws a TypeError. However, you should not rely on Jangaroo code not throwing TypeErrors!

Note that there are also implicit type coercions in AS3 (e.g. var i:int = 42.5), which we are planning to implement in a future Jangaroo release.