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.

The metaphor is particularly useful when trying to balance the desire to create maintainable code with business demands for quick results. Incurring the debt may be a sensible, strategic business decision, but one should always plan on paying off the debt later, and how much later affects the interest payments accrued in the meantime.

This is particularly pertinent at the moment since one of my clients is looking to hire a Flex developer and I’m helping out with the interview process. (If you’re an experienced Flex developer in London and want to be considered, drop me a line. I can’t promise to reply to everyone, but I’ll pass your details on to my client.)

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.

No data is entirely secure, and if anyone else has access to your webserver (the company managing the server for you?) or your database (the company storing the backups?) then you don’t have total control over the security anyway. So there’s always a chance your database could be stolen. So, the simple rule is to hash your passwords.

Hashing

A hash is a string derived from the original password via a one-way algorithm. In other words, it’s easy to create the hash from the original, but harder (when used for security, ideally impossible) to create the original from the hash. You store the hash in the database, and when the user signs-in you hash the password they sign-in with and compare it to the hash in the database. Something like this

if( $user->passwordhash == sha1( $_POST['password'] ) )

That way, you never store the user’s password.

There are a number of hashing algorithms in PHP, of which md5 and sha1 are the most commonly used. Unfortunately, neither is as secure as they were once thought to be. It would be better to use a more secure hash, and if you have the Hash engine in your PHP installation (included by default since PHP 5.1.2) then you have access to many more algorithms. So a better example would be

if( $user->passwordhash == hash( 'whirlpool', $_POST['password'] ) )

Rainbow tables

But there’s another problem. Once your database is stolen, the thief has plenty of time to crack the passwords using a simple Rainbow Table attack. This involves creating a large selection of hashes based on likely passwords (e.g. every word in the dictionary) and then comparing the hashes with the hashes in your database. Within an hour or so, half the passwords in your database will probably have been cracked.

To prevent this you should salt each password by adding a random string to it (called a salt or nonce). The time consuming part of a rainbow table attack is building the dictionary of hashes. Adding a random salt to the password means the thief has to build a whole new dictionary of hashes for each salt, making a rainbow table attack too time consuming to be viable. Each password should have a different salt, and the salt doesn’t even need to be secret.

The Code bit

So, for secure passwords you need code that looks something like this

// get a new salt - 8 hexadecimal characters long
// current PHP installations should not exceed 8 characters
// on dechex( mt_rand() )
// but we future proof it anyway with substr()
function getPasswordSalt()
{
    return substr( str_pad( dechex( mt_rand() ), 8, '0',
                                           STR_PAD_LEFT ), -8 );
}

// calculate the hash from a salt and a password
function getPasswordHash( $salt, $password )
{
    return $salt . ( hash( 'whirlpool', $salt . $password ) );
}

// compare a password to a hash
function comparePassword( $password, $hash )
{
    $salt = substr( $hash, 0, 8 );
    return $hash == getPasswordHash( $salt, $password );
}

// get a new hash for a password
$hash = getPasswordHash( getPasswordSalt(), $password );

You don’t have to attach the salt to the hash, you can instead store them separately within the database, but I like keeping them together in a single string. Equally, the salt needn’t be in hexadecimal, but I like the symmetry with the hexadecimal hash.

Finally, as Thomas Ptacek points out, you don’t want the fastest hash algorithm in the world for this – a fast algorithm is more useful to an attacker than it is to you.

So this morning I was experimenting with various other possible ways to create singletons in Actionscript 3 and came up with a function that can be used to create and reuse a single instance of any class. I don’t know how useful it will turn out to be but here it is. It’s also a useful example of a package level function.

package
{
    function Singleton( c:Class ):*
    {
        for( var i:String in instances )
        {
            if( instances[i].constructor === c )
            {
                return instances[i];
            }
        }
        var obj:* = new c();
        instances.push( obj );
        return obj;
    }
}
var instances:Array = new Array();

You can use this function to create an instance of any class (your own or an intrinsic class) as follows (for example):

import flash.geom.Point;
var a:Point = Singleton( Point );

if you request another point elsewhere in your project, for example

import flash.geom.Point;
var b:Point = Singleton( Point );

you will get the same point back again.

The one problem is the need to loop through all previously created singletons looking for a match before creating a new one. The more singletons you create, the slower this will be. It’s probably fine since most applications only use a few singletons but it would be great to get a unique identifier directly from the class and then look up the matching singleton directly. I can get the class name via the toString method, but would also need the full package to ensure uniqueness. Any ideas?

Like I said, I’m not sure how useful this function will be but it’s here if anyone wants to use it. If you improve it then please let me know.

Postscript

In the comments below, Benny suggested a way to remove the loop, and so gain a more stable lookup time, by using a Dictionary instead of an Array. His suggestion, with minor alterations by me, looks like this.

package
{
   function Singleton( c:Class ):*
   {
      return c in instances ? instances[c] : instances[c] = new c();
   }
}
import flash.utils.Dictionary;
var instances:Dictionary = new Dictionary( false );

Thanks, Benny.

The new blogs cover a range of information related to software development and project management. If you’re a developer, project manager or even CEO and you’re interested in improving the way you develop software there’s a number of gems on these blogs already. So go take a look.