Tag Archive for 'Compiler'

AS3 is weird. True story!

Well, every experienced AS3 developer once in a while faces weird things in our beloved ActionScript 3. Sometimes it’s funny but usually it isn’t, because results in hours of wasted time. Blooddy, my Belorussian friend, compiled some of the obstacles he faced in the past into the series of short microblog posts. In this post I’ll try to translate those posts in English adding my own experience.

OK, I don’t know where to start, so the order here means nothing. Let’s start.

1. LOL! ME BROKED TEH FLASH VERIFEIRZ!!!

for ( 	var i:uint = reversed ? array.length-1 : 0;
    reversed ? i >= 0 : i < array.length;
    reversed ? i-- : i++ ) {
}

This code compiles perfectly but results in a huge bytecode dump and a weird error — VerifyError: Error #1030: Stack depth is unbalanced. 1 != 0.

Don’t ask me how I got to this code.

2. Object vs. Object

var a:Object = {};
a["a"] = 1;
a["b"] = 2;
a["c"] = 3;
for ( var v:String in a ) {
    a["a"] = 2;
    trace(v, a[v]);
}

How do you think what this code will result into? You would guess something like

a 2
b 2
c 3

But it’s actually

a 2
a 2
c 3

for me.

If you change the first line to

var a:Object = new Object();

you’ll get

b 2
a 2
c 3

Of course Adobe didn’t promise order in collections which Objects are. Also, modifying a collection while working with it looks wrong anyway. But how come new Object() and {} differ so much, as far as I remember everyone says that both these constructs create an object, the later one just can handler properties to set. Apparently it’s not right.

Actually {} results into just one opcode NewObject while new Object() results in 2 opcodes: look for class, create class (sorry, will change for actual opcode names later). Anyway, you should be aware of this fact.

3. Where did this Security Error came from?

Imagine that we have a Socket object. We want to connect to some server but it’s down. We got IO Error and want to remove all listeners from Socket events and BOOOOM! we get a Security Error because Flash couldn’t get socket policy file (undoubtedly).

Who knew that right after IO Error we’ll get a Security Error?

4. Who called this .load() ?

Imagine we have a class extending Sound.

public class S extends Sound {
  public function S() {
    super();
  }
  public override function load(stream:URLRequest, context:SoundLoaderContext=null):void {
    throw new Error( 'ZOMG PEW PEW!!!1' );
  }
}

How do you think, what will we get after executing var s:S = new S(); ?

Right, we’ll get ZOMG PEW PEW!!!1 because despite of Flash help saying “If you pass a valid URLRequest object to the Sound constructor, the constructor automatically calls the load() function for the Sound object.”, constructor actually calls .load() anyway.

5. Super()? What super()?

Continuing #4, what if we could block parent constructor of being executed… But we can’t, if you don’t specify super() call compiler will add it automatically. Well, we could add it somewhere where it won’t be executed.

if ( false ) {
  super();
}

But damn, compiler is smart. But not so smart to overcome this:

if ( !true ) {
  super();
}

Or it knows something we don’t! Apparently !true isn’t always false. But we can skip executing super constructor until Adobe fixes it.

6. GET MY CHILD BACK YOU BIATCH!!!

Imagine that we have a Container extends DisplayObjectContainer which overrides removeChild() method to throw exception so bad people couldn’t remove children from it.

Let child:DisplayObject be a child of container:Container, now look at the code

var s:Sprite = new Sprite();
s.addChild( child );
s.removeChild( child );

Apparently, it bypasses our overridden method and STEALS OUR CHILD!!!!1

7. Wait, so many loaders… I’m confused…

All the time we use loaders of different kinds: Loader, Sound, URLLoader, URLStream, FileReference. So why are they so different?

1. Loader.

  • First of all it extends DisplayObject, maybe that’s why everything loading related is in contentLoaderInfo (this is what makes me mad every time).
  • load(request:URLRequest, context:LoaderContext = null):void
  • bytesLoaded:uint (read-only)
  • bytesTotal:uint (read-only)
  • url:String (read-only)

2. Sound.

  • load(stream:URLRequest, context:SoundLoaderContext = null):void
  • bytesLoaded:uint (read-only)
  • bytesTotal:int (read-only)
  • url:String (read-only)
  • Doesn’t have httpStatus event

3. URLLoader.

  • load(request:URLRequest):void
  • bytesLoaded:uint (read-write)
  • bytesTotal:uint (read-write)
  • Also, why all URLLoader’s properties are public variables not accessors?

4. URLStream.

  • load(request:URLRequest):void
  • No bytesLoaded or bytesTotal, but at least we get a progress event

5. FileReference.

  • We get 3 methods to load data: load, download, upload
  • No bytesLoaded or bytesTotal, but at least we get a progress event

And last, ProgressEvent has properties bytesLoaded (read-write) and bytesTotal (read-write). Both of type NUMBER.

So if you want to implement your own universal loader you must know all these differences.

8. Missing TextField.

Flash says that inheritance chain for TextField is the following: TextField -> InteraftiveObject -> DisplayObject -> EventDispatcher -> Object. Apparently there’s DisplayObjectContainer missing because we can do the following:

public function test() {
  var t:TextField = new TextField();
  t.addEventListener( Event.ADDED, this.handler_addedToStage )
  t.width = 400;
  t.height = 200;
  t.htmlText = ' <img src="http://www.google.ru/logos/olympics10-hockey-hp.png" />';
  super.addChild( t );
}
private function handler_addedToStage(event:Event):void {
  if ( event.target == event.currentTarget ) return;
  trace( event.target );
}

The code results in

[object Loader]
[object Sprite]

It means that we can grab Loaders for HTML images and preload them. Also we can reparent them using the trick above (8

9. Hi, I am addedToStage! Hi, I am addedToStage!

Here’s the code:

public function test() {
  var s1:Sprite = new Sprite();
  s1.addEventListener( Event.ADDED_TO_STAGE, handler );
  super.addChild( s1 );
}

private function handler(event:Event):void {
  var s2:Sprite = new Sprite();
  s2.addEventListener( Event.ADDED_TO_STAGE, trace );
  ( event.target as Sprite ).addChild( s2 );
}

Do you expect to see only one trace? Nope, you’ll get TWO!

And here’s why. We know that addedToStage event is dispatched in the addChild() method. After executing it must tell all children that they were added to stage too. So, when we add a new object to display list in handler() it first gets its own event and after that execution flow returns back to super.addChild() where it tells all its children about them being added to stage. And there’s where the second event comes from.

Of course if we add more children objects we’ll get more misleading events.

10. __AS3__.vec

The Vector class is kind of mysterious. Flash help says that it is top level class but actually it relies in virtual package __AS3__.vec which doesn’t actually exists but is made by compiler.

Looks like a patch which is there since some early beta of Flash Player 10.

HOORAY!

That’s all for now. If you have something to add to the list feel free to mail me or leave a comment here.

MXML in AS3 projects and fixing mxmlc

Not many people actually know that you can use MXML in pure AS3 projects. Here’s an example.

Create a new AS3 project, create a new file in package cp. Call it App.mxml. Flex Builder will not allow you to create an MXML component in a pure AS3 project, so you have to do it manually. Here’s my App.mxml.

<?xml version="1.0" encoding="utf-8"?>
<cp:Component xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:cp="cp.*" >
    <cp:Component var1="123"/>
    <cp:Component var1="124111"/>
    <cp:Component />
</cp:Component>

Notice that I’m using my own namespace and no flex components. Now define Component class in cp/Component.as.

package cp {
import flash.display.Sprite;

[DefaultProperty( "children" )]
public class Component extends Sprite {
    public function Component() {
        super();
    }

    private var _children:Array;
    public function get children():Array {
        return this._children;
    }
    public function set children(value:Array):void {
        this._children = value;
        trace( value );
    }

    public var var1:String;
}
}

In main project file I put:

package {
import cp.App;
import flash.display.Sprite;

public class mxml_test extends Sprite {
    public function mxml_test()
    {
        this.addChild( new App() );
    }
}
}

To compile it you need to have framework.swc in library path though. And [DefaultProperty( "children" )] doesn’t work neither in 3.4 SDK nor in 4.0 for some reason. People say it should work in 4.0 but it doesn’t.

That’s weird that Flex SDK 3.4 and Flex SDK 4.0 produce different code from MXML files. 4.0 adds much more useless Flex stuff to resulting SWF. If you want you can add -keep-generated-actionscript compiler parameter to check converted code. Flex 4.0 adds such functions for every object in original MXML.

private function _App_Component2_i() : cp.Component {
    var temp : cp.Component = new cp.Component();
    temp.var1 = "123";
    _App_Component2 = temp;
    mx.binding.BindingManager.executeBindings(this, "_App_Component2", _App_Component2);
    return temp;
}

I don’t like that executeBindings thing in my code and useless mx.* classes it puts in SWF making it 3.5Kb in size. So I decided to patch Flex SDK since it’s kind of open source. Flex SDK SVN can be found at opensource.adobe.com/svn/opensource/flex/ and it contains everything you should need to rebuild your own version of SDK. These links helped me a lot too, and thanks God I found those Eclipse projects inside after trying to resolve libraries issues for an hour.

There are only 2 places where I found this executeBindings stuff, both classes are in flex2.compiler.mxml.gen package. I commented this code and compiled mxmlc.jar. I’ve been doing it all evening but couldn’t get rid of it. I can’t get why. I am totally sure that new mxmlc.jar is used but this stupid string is there anyway.

I consider the final result to be a failure but at least I now know that you can patch Flex SDK as you wish. But I didn’t have time to try to understand how the whole compiler code works and where it handles bindings exactly. I didn’t find much on the internet so I guess not many people actually tried to build their own versions of compiler.