I like to think that Robert may have been inspired in part by my work with events in AS2, but I doubt it.

The conversation’s just kicked off on Twitter and Robert’s Blog. Josh McDonald in particular has already made some good suggestions. My comments on bubbling are awaiting moderation.

The argument for

The only argument I’ve heard in favour of this practice is that it enables a developer to know whether a type is a class or an interface just by looking at the name, but I’m not convinced.

It’s more confusing

Looking through the core Actionscript classes, I do a double-take at classes like ID3Info – (What’s a D3Info? Oh, it’s a class not an interface.)

Or, consider what might happen if you were creating an application that interacts with mobile phones. You are very likely to have a type called IPhone. But is that a standard phone interface that all phone classes should implement? Or is it a class for the iPhone implementation?

Same name, different type

And it’s not just confusion over whether something is an interface or not. What makes a class an EventDispatcher? Is it any type that extends EventDispatcher, or is it any type that implements IEventDispatcher. The I is just a prefix indicating that a type is an interface, so we have two EventDispatcher types. Without the I prefix this wouldn’t be possible.

But we copied it from Java, didn’t we?

Actionscript developers have adopted the I prefix because Adobe did so. But why did Adobe adopt this idea? Common thinking is that they adopted the idea from the Java community, which sounds plausible. Many of the ideas in Actionscript originated in other languages.

However, using an I prefix on interfaces isn’t a standard in Java. In fact, it’s just the opposite. Look at any of the Java core api, or any other code developed by Sun, and you’ll not see an I prefix on the interfaces. And it’s not just Sun, many other large Java development companies don’t use the I prefix (Google, for example). Far from being a Java standard, the I prefix is an aberration adopted in some corners of the Java world, possibly by ex-Microsoft developers.

Hungarian Notation

Why ex-Microsoft developers? Because Microsoft used to use Hungarian Notation in all their code (Charles Simonyi, who invented Hungarian Notation, became chief architect at Microsoft). The reason Hungarian Notation works is because it requires every name to have a prefix. So iPhone is the Phone interface (i prefix for interface) and cIPhone is the IPhone class (c prefix for class).

Mixing it

Problems occur when only some names have prefixes, as with the I prefix for interfaces and no prefix for classes. Unfortunately, this is the pattern that Adobe have adopted for Actionscript (and that Microsoft have adopted for C#, but even C# isn’t perfect).

So…

This is why I don’t use the I prefix on interfaces in any of my code, including Flint.

Joa Ebert discussed this in his presentation at Flash on the Beach. I already use specific object pooling in the Flint particles library, but while he was talking I had an idea and wrote a class for generic object pooling of all object types. I finally had time to test the class, and it works as expected, so I’ve added it to my open code repository, where you can download it.

The object pool class manages pooling of all objects through two simple methods. You can obtain an object from it like this

var obj:SomeClass = ObjectPool.getObject( SomeClass );

If there are any such objects in the pool, one of them will be returned. If there are no such objects in the pool, a new one will be created and returned to you.

When you no longer need an object, you can add it to the pool for later reuse like this

ObjectPool.disposeObject( obj );

The object doesn’t have to have been created through the pool – any object can be dropped into the pool with the disposeObject method.

The source code is available in my google code repository.

For some developers that’s not a problem since memory use is quite low on lots of web sites, and all the memory is freed when a user leaves the web site anyway. However, with the development of rich applications on the web and in Air, garbage collection is becoming an issue that more developers need to understand.

I was going to write a long post explaining garbage collection, but Grant Skinner got there two years before me. Here’s his useful series about resource management in Flash.

When you’ve read that, this more recent post by Sean Christmann adds further insight – Kick starting the garbage collector.

Now there’s no excuse for leaving trash lying around.

addEventListener( MouseEvent.CLICK, clickHandler );

function clickHandler( event:MouseEvent ):void
{
	// function body here
}

What the documentation says

The (usually excellent) Flash and Flex help isn’t much help here. In the Actionscript 3 language reference, it states that the parentheses "Surrounds one or more parameters and passes them to the function that precedes the parentheses", which doesn’t explain why (or even if) the parentheses are necessary when no parameters are passed to the function.

Elsewhere in the help, it states that "If you are calling a function with no parameters, you must use an empty pair of parentheses". No explanation – just do it. Which inevitably leads to developers wondering why they mustn’t do it when assigning event handlers.

Colin Moock’s Essential Actionscript 3 (also usually excellent) takes a similar approach, simply stating "Notice the important and mandatory use of the parentheses operator following the method name".

People learn things better if they understand them, so here’s my attempt at an explanation. If you’re confused about when to use the parentheses operator this should help. If not, come back tomorrow when I’ll post something a lot more advanced about programmatic skins in Flex.

What the parentheses operator does

A function is a portion of code that performs a specific task or set of tasks within your application. The function may be something you have defined, or it may be an intrinsic function (a function built-in to the flash player, like the trace function). When a function is a property of an object, it’s usually called a method. Here’s a trivial example function definition.

function sayHello():void
{
	someTextField.text = "Hello";
}

The code inside the function is run by calling the function, like this.

sayHello();

The parentheses could perhaps be better named as the function calling operator since that is what they do. We use the function’s name to refer to the function, and then we use the parentheses to run the function we have identified.

If the function needs some additional information in order to run (the parameters) then that information goes inside the parentheses.

function saySomething( thingToSay:String ):void
{
	someTextField.text = thingToSay;
}

saySomething( "This is a boring example" );

But the parentheses, with or without parameters, are the operator that calls the function.

What happens without the parentheses

If that’s what the parentheses are for, what happens if we leave them out? Like this

sayHello;

Well, first of all, you won’t get an error. sayHello exists (it’s defined above) so the code is valid. But, it doesn’t do anything. We have used the name of the function (“sayHello”) to refer to the function, then we’ve done nothing with it. When you put the parenthesis after the function you are indicating that you want to call the function now. Without the parenthesis, you’re not running the function. But calling a function is not the only thing we can do with it.

For example, we can assign it to a variable, like this

var myFunction:Function = sayHello;

Now we can refer to the function via the variable. So if we used the parenthesis operator on the variable, it would call the function, like this

myFunction();

Or we could continue to use it’s original name, like this

sayHello();

Event handlers

When we set up an event handler, we don’t want to call the function straight away, we want the event handler to call the function later, when the event happens. So, we define an appropriate function

function clickHandler( event:MouseEvent ):void
{
	someTextField.text = "The mouse was clicked";
}

Then we assign the function as a listener for the event

addEventListener( MouseEvent.CLICK, clickHandler );

When we assign the function as a listener, we don’t want to call the function, so we don’t use the parentheses operator. Later, when the event actually happens, the flash player will call the function for us. There’s some code inside the EventDispatcher class that uses the parentheses operator to call the function when the event happens.

If you make the mistake of using the parentheses operator when assigning the event handler, like this

addEventListener( MouseEvent.CLICK, clickHandler() );

then the event handler will be called immediately (you’ve told it to do so by using the parentheses). This will usually generate an error since you haven’t assigned a parameter for the event argument.

So that’s the parenthesis operator. Personally, I like the way that C++ names the parentheses operator the "function operator" – it’s the operator that calls a function.

for( var i:uint = 5; i >= 0; i-- )
{
    // do something here
}

The answer, of course, is never. The loop continues indefinitely because a uint can never be less than 0. Doh!

The code is in a single class called RadialPerlin, used like this

var perlin:RadialPerlin = new RadialPerlin( 100, 3, 
        Math.random() * 100000, false, 15, false, true );
perlin.draw( 0, 0 );
var bmp:Bitmap = new Bitmap( perlin.bitmapData );
addChild( bmp );

Download the RadialPerlin class and demo.

The RadialPerlin object is initialised with some values (details of the parameters are in the class file) then drawn into a BitmapData object using its draw method. The draw method takes a couple of offset parameters – one for the distance from the centre and the other for the rotation. You can then grab the BitmapData object from the RadialPerlin object via its bitmapData property and do what you like with it.

The code is licenced under the MIT license. Have fun, and if you make something interesting with it let me know.

In Actionscript 2 this was a simple matter of calling Key.isDown() with the appropriate key code. But in Actionscript 3 Key.isDown no longer exists and the only intrinsic way to react to the keyboard is via the key up and key down events.

To rectify this I created the KeyPoll class, which has isDown and isUp methods, each taking a key code as a parameter and returning a Boolean. The class and an example of its use are in my free code repository.

The class uses a ByteArray to hold the current keyboard state, which is updated in response to Keyboard events and queried by the public methods, isDown and isUp. Using a ByteArray is more compact than using an Array of Booleans, and in tests it also turned out to be marginally faster, although the difference in speed was not significant enough to matter.