But that’s always the programmer’s fault, of course. It turns out Javascript isn’t made to be used in a object-oriented way, but rather in a prototype-oriented fashion.

This lengthy post compares Java and Javascript and explains how a Javascript programmer should implement object inheritance.

I found a few things strikingly useful in there, notably the delegation of the whole obj.prototype reference and the fact he never explicitly declares any class attributes as he does in Java (and how I was trained to do it).

class Utils {
// Desc		:	Usually, when you attach a function to an event, you can't pass
//			parameters, using this function instead of the Delegate class
//			will allow you to do the same thing but with unlimitted parameters
// 			Window: General Information.
// 			http://www.person13.com/articles/proxy/Proxy.htm
public static function delegateEvent(oTarget:Object, fFunction:Function):Function {
    // Create an array of the extra parameters passed to the method. Loop
    // through every element of the arguments array starting with index 2,
    // and add the element to the aParameters array.
    var aParameters:Array = new Array();
    for(var i:Number = 2; i < arguments.length; i++) {
        aParameters[i - 2] = arguments[i];
    }
    // Create a new function that will be the proxy function.
    var fProxy:Function = function():Void {
        var aActualParameters:Array = arguments.concat(aParameters);
        fFunction.apply(oTarget, aActualParameters);
    };
    return fProxy;
}

And you can call it like this:

private function someFunction():Void {
    this._xml.onLoad = Utils.delegateEvent(this, xml_onLoad, "GeneralInformation");
}

private function xml_onLoad(success:Boolean, nextStep:String):Void {
    if(success)
    // Get the contents of xml
    switch (nextStep) {
        case "GeneralInformation" :
            this.open_GeneralInformation(); break;
    //etc...
    }
}

This was a huge time savor and suits how I like to write code.

class Foo {
	public var _someProperty:String
	public function Foo() {
		// Lets skip how I actually make the button,
		// but I usually use .attach() and I make
		// exportable the object in the Library. I
		// think I should use createClassComponent however.
		var but:MovieClip = new MovieClip();
		but.onPress = function () {
		_root.MyFooObject._someProperty = “Clicked”;
		}
	}
}

To access my attribute, I must leave my class and follow the absolute, practically hard-coded, path to my value. It’s really not a good thing to do. Instead, I found you can use the Delegate class to forward events to a function inside the parent class. Like this:

class Foo {
	private var _someProperty:String
	public function Foo() {
		// Lets skip how I actually make the button here too.
		var but:MovieClip = new movieclip();
		but.onPress = mx.utils.Delegate.create(this, button_onClick);
	}
	private function button_onClick():Void {
		this._someProperty = “Clicked”;
	}
}

Where “this” means the class you are in (could be another one), and “button_onClick” is the name of the function you will be calling after the event is triggered.

There you go! It’s a lot more powerful, much more logical from a semantic point of view and it makes the code a lot clearer. Notice how I can protect my call properties now using the private attribute.

Speaking of being semantic, you always should call you call properties with “getters and setters” instead of calling it directly like I did in my example. It should look like this instead:

private var _someProperty:String
public function get someProperty():String { return this._someProperty;}
public function set someProperty(val:String):Void {
    // validation if needed; this._someProperty = val;
}

One of the components I’ve played with it the Window object. It’s simple to understand and it’s possible to create a Window on the fly using ActionScript only. Let me put some emphasis on that. Within a few lines, I was able to program my way into a graphic application. We can all agree that’s the goal behind the general direction Macromedia is taking and to a certain extent they are succeeding in doing so.

However, other components are much harder to instantiate or create/call straight from ActionScript. The documentation on Live Docs is also somewhat deficient. I’ve tried a gazillion times to have the XML connector work when created dynamically but couldn’t make it work yet. The media playback was a bit easier to build with dynamic values, but as I write this, the Mp3 player on The Music Tank still has trouble opening .mp3 files consistently.

What I hate about components is how I never know if it’s my fault if it’s not working. If it is (which is probably the case) there are two questions I can rarely find answers for:

• Am I supplying invalid values which failed validation once the control is speaking with my website? And
• Is the control not working because I instantiated its properties with wrong values?

I hope Flex will make it easier for graphic artists who are able to do real Object-Oriented programming. Right now, I feel pretty dumb having to use illogical code just to make up for Flash’s “almost-there” programming language.