constellex

Maybe it’s just me, but I think most programmers would agree: some languages are just more beautiful than others. Beautiful is of course a relative term, but many programmers would probably agree it’s due to some complement between structure and simplicity. From a personal standpoint, I find Java to be well-structured, yet still beautiful. I also find Ruby to be simple from a verbosity point of view, which probably attributes to its beauty.

ActionScript looks very similar to Java. In fact, almost exactly like Java. I would probably compare it more closely to C#, but apples to apples, am I right? Either way, there is something inherently bad looking about it…something we all hate to love. It looks a lot like JavaScript. Here’s some examples:

public var myVar:String = "My string";

public function myFunction(o:Object):int{}

What irks me is that with a few changes the language would look just like Java/C#, providing two benefits: No unnecessary syntax and ease of learning for developers who already know those languages. Let’s pick apart the examples.

In the first example there’s two problems. For one, what is the point of specifying “var”? It seems pretty obvious to me that we’re creating a variable as there’s no syntax for parameters or a function block, so we’re definitely not creating a function or class. You might say they are trying to keep consistency with declarations, but with a variable, we aren’t defining structure, we’re defining an instance of something that has already been defined. Why not change the syntax to something a bit more understandable in my opinion:

public String myStr = "My string";


We’ve simplified the ActionScript code greatly. For one, it is more obvious that this object is a string. We’ve also removed the whole var nonsense. By mixing the variable name with its type, it makes for a little bit harder to read code: “myStr:String”. It’s hard to explain, but it seems unnatural to me to say: “I’m creating a variable named myStr. It is a String. It has this value.” It may look fine at its surface, but as a programmer, I would prefer to start generic and get into more details as I go: “I have a String. Its name is myStr. Its value is ‘My string’.”

Let’s tackle the second line of code. It has the same problems as the first essentially. What is the point of saying “function”? If it is to keep the pattern of stating what things are when defining their structure (Classes, packages, etc.), then I’ll allow it. Again, I would prefer to switch the entire function prototype around to something like this:

public int myFunction(Object o) {}


We’ve removed the unnecessary function declaration and also made it more clear what this function returns, as well as what types it accepts as its parameters. Why do I like having the return declaration to the left of the function name as opposed to the right? Well, let’s think logically and apply how we generally call functions. When you call a function, you tend to set its returning value to a variable, and just like in math and most programming languages using infix notation you have the variable on the left side and equation on the write. We can think of a function as the equation being solved and the result being stored on the left side of the equation. It just seems natural.

Maybe it’s just me, maybe I’m just picky about the look of my code. Ask Chris, I’ll have a fit if people put their curly braces on the next line after a function declaration, or if they don’t use curly braces after block statements that contain only one line of code after it, or if they don’t comment. Will Adobe ever change ActionScript to look more like how I’d like? Probably not. But this post goes out to those who find ActionScript a bit unnatural.

Well, that’s it for the roast of ActionScript. I could post about how it has no collections framework, but that’s outside the scope of the language in my opinion. Overall, ActionScript 3.0 is an improvement over its older versions (Except for the removal of private constructors), and it will only lead to more powerful Flash applications. Of which, we hope to show you in the near future.

Overloading methods, or functions, is an extremely powerful technique available to programmers in many object-oriented languages (Including Java, C++, etc.). Adobe, however, decided to leave this functionality out, which was a cause for many unexpected design changes to my recent ActionScript project. As a brief review, or introduction for programmers new to object-oriented programming, overloading methods allows for various different strategies. For example, we could have a method with the following prototype:

public boolean parse(String myStr);

As well as another method in the same class with the following prototype:

public boolean parse(int myInt);

There are a couple benefits we gain by being able to use this technique. For one, we could use this technique to simply allow a programmer using the class to be able to pass either a String or int to the parse method. A sample implementation in Java might be:

public boolean parse(String myStr) {

	// perform parsing algorithm on myStr

}

public boolean parse(int myInt) {

	return parse(String.valueOf(myInt));

}

Sure, the programmer that needs to use this class could simply cast/convert the integer to a String first and then call parse, but this makes things a little bit simpler for them. Overloading, however, gives us even more flexiblity. What if the parsing algorithm needed to change based on the object passed in? You couldn’t accomplish this with ActionScript 3.0 since it does not support method or constructor overloading. The rules are simple. You cannot have a method named the same as another method, regardless of differing return types or parameter lists.To the advanced programmer, you can see how limiting this is. How do we solve it? Well, to be honest, some of the cases I’ve pointed out can’t be solved in ActionScript 3.0. If you want to provide different algorithms based on the passed in object(s) via the same method name, you can’t, you need to make different methods with different names.If it is absolutely necessary that you support multiple algorithms based on the parameter passed in, you need to look into implementing the Strategy pattern. If you don’t need all of the overhead of an interface with concrete algorithm classes from the strategy pattern, you can hack this functionality in like so:

public function parse(o:Object):Boolean {

	var retVal:Boolean = false;

	if ( o is String ) {

		retVal = parseStr(o as String);

	} else if ( o is int ) {

		retVal = parseInt(o as int);

	}

	return retVal;

}

public function parseStr(myStr:String):Boolean {

	// Algorithm for strings here

}

public function parseInt(myInt:int):Boolean {

	// Algorithm for integers here

}

Yes, that’s hideous. Each time you want to be able to parse another type of object you need to add another function and modify the original parse one. Oh, and there’s no compile time checking to make sure that users of your class aren’t passing in an instance of Object that isn’t supported. So you’d need to add functionality to throw an exception. Hopefully Adobe adds method overloading in 4.0. Next up for part 3, unnecessary syntax.

ActionScript 3.0 is the new version of the Adobe Flash scripting language. ActionScript 3.0 is supposed to be a better implementation of Object-Oriented paradigms. Through my learning of ActionScript on my latest project (A XML Object-Relational Mapper between web services), I have come across several gotchas and frankly annoying things about ActionScript.

I will be doing a several part series on the various problems I’ve encountered using ActionScript and how to get around them or how Adobe should fix them. Either way, knowledge about these things is important to the typical OO programmer looking to learn ActionScript.

Private constructors. Although not the most commonly used feature of most object-oriented languages, they are essential for one of the most famous, or infamous depending on the programmer, design patterns. The Singleton. For those not in the know, the Singleton pattern is used for enforcing only one instance of a specified class. There are many uses for this, but I’ll leave that discussion to a place with a little more room.

ActionScript 3.0 is missing private constructors. This is intriguing for two reasons. One, private constructors were allowed in ActionScript 2.0. Two, private constructors were removed with what seems to be no reason. I have been unable to find any documentation as to why they were removed. This makes implementing the Singleton pattern rather strange. So how do we do it?

package com.constellex.actionscript {

	import flash.utils.getQualifiedClassName;

	public class Singleton {

		private static var instance:Singleton = null;

		public static function getInstance() : Singleton {
			if (Singleton.instance == null) {
				Singleton.instance = new Singleton();
			}
			return Singleton.instance;
		}

		public function Singleton() {
			if ( getQualifiedClassName(super)
				!= "com.constellex.actionscript::Singleton" )
				throw new ArgumentError();
			} else {
				// Your constructor code here
			}
		}

	}

}

The only difference this ActionScript 3.0 implementation does differently is that instead of checking at compile time whether you are correctly using the Singleton object, it will throw an ArgumentError exception if you attempt to instantiate the Singleton object outside of the Singleton class. The getQualifiedClassName(super) gets the name of the class calling the method, which allows the Singleton to check and make sure only the Singleton class can call the constructor.

Next up in part 2, overloading methods.