The I in Interface

I’m often asked why the interfaces in Flint don’t start with a letter I. The simple reason is that I think this practice, while common among Actionscript developers, is so seriously flawed that it’s better not to do it, even if it is common among other developers and may cause some initial confusion for some.

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).


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

Technical Debt

It seems particularly relevant during this credit crunch to be talking about Technical Debt – the debt you owe when implementing a solution in a quick and dirty way, which accrues interest every time you need to alter or add to the code, and can be paid off by taking time to refactor the code.

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.

Hiring developers

A recent post by Jeff Atwood reminds us why you should avoid, at all cost, hiring poor developers. A poor developer will pull the whole team down, often producing negative productivity due to their impact on the rest of the team (and on the codebase). So when hiring the rule should be “if in doubt, say no”. When I forget this, I turn back to Joel Spolsky for a reminder. Then Steve Yegge, whose blog I love reading, for his inevitable twist on the subject.

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.)

Garbage Collection

I recently received a support query on Flint regarding garbage collection. In discussions on the forum I was reminded that many Actionscript developers don’t know how the Flash Player’s garbage collection works.

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.

PHP Password Security

If you build websites that require users to register it’s your responsibility to keep their passwords safe. And if you’re storing the passwords in plain text then you’re not doing your job properly. It may be that, like Reddit, you think that storing passwords in plain text leads to a better user experience. I happen to agree with you. But then, like Reddit, what happens if your database is stolen? It’s not just your site that is compromised. Since most users use the same password on multiple sites, all those sites have also been compromised.

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.


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.