« Flint Particles in Flex | New line renderers in Flint »

The I in Interface

6th August 2009

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

So…

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

Tags: Actionscript, Best practice

14 Comments add your own

How bizarre that anyone could have thought we Java devotees supported this silly I- prefix. Not on your life. (I might add that if anything, it’s the *implementation class* that should have the funny prefix, not the more widely seen interface.)

Kevin Bourrillion | 6th August 2009 at 21:02
The only argument I pose is usability to the user that is using the library. Using the “I” helps the user avoid classes that are not suppose to be used for instancing. For a large library, I can foresee a user making several hundred mistakes when accidentally using an interface class instead of a closely named class that uses that interface.

Jonathan :: JADBOX.com | 6th August 2009 at 22:06
Well I was one of the people who asked so maybe I should comment.

On the little bit of use I had with Flint I found it impossible to know what was a interface and what was a class unless I looked the item up in the docs or opened it myself, which wasn’t great.

That said there are a few classes in AS that could be mistaken for an Interface if this name convention is followed, but they are few and far between.

You mention above that using this naming convention is more confusing. That might be the case in other languages, or to yourself, but it’s a widely adopted convention to ActionScript developers. It’s what a huge percentage of us are used to, and therefore not following the convention causes more confusion than any it might clear up through the points you made above whether they are valid or not.

Tink | 7th August 2009 at 11:14
I agree that the I-convention feels a bit silly, especially since good development tools like Flex Builder are able to distinguish between interfaces and classes and show this in the code hinting (using different icons). For people who are using the Flash IDE for their ActionScript development, the I-convention might make more sense, since the code editor in the Flash IDE doesn’t give the same level of code hinting (it’s just plain bad).

But like Tink said, using I in interface names is a convention pushed by Adobe and thus the majority of the developer community is used to this. In order for this to change, I think Adobe must first change it’s recommendation. For Adobe to change it’s best practice recommendation in regards to this you would need to get in touch with the right people there or start up a campaign like “Make some noise” to persuade them to change it.

Based on your post, I’m again re-evaluating if I should follow the current conventions, or if I should join you on the fences. I recognize the problem you describe in the IPhone case. Another example would be if you have say an Internet interface. Should you name it IInternet (which looks just dumb and is prone to typos) or should it be Internet (which might confuse a new developer into thinking it’s a concrete implementation)?

Jens Wegar | 7th August 2009 at 21:13
@Kevin – Strange though it may sound, I know more than one Java developer who was told at university that interfaces in Java should be prefixed with an I.

Richard | 8th August 2009 at 13:18
@Jonathan – Any decent dev environment should immediately recognise when you are trying to extend an interface or implement a class and highlight the mistake.

I think a more pertinent point is the false impression that EventDispatcher is the base type for event dispatcher – an impression that most beginner and intermediate Actionscript developers seem to have – when in fact IEventDispatcher is the base type.

Richard | 8th August 2009 at 13:19
@Tink – Would you really try to use a library without either looking things up in the docs or looking at the source code?

More seriously and to draw a parallel – Adobe set the convention for naming packages with their base packages of flash and mx. What do we infer from this? – When creating a library choose a pertinent word to use as the package name and place your code inside.

But neither you or I do this. I don’t place my code in base packages called bigroom and flint, and you don’t place your code in a base packages called tink and efflex. Why? Because we both know it could result in name collisions. It’s not very likely (I don’t know any other developers, companies or projects called tink or efflex), but just in case it might happen, you place code in the packages ws.tink and org.efflex and I place mine in the packages uk.co.bigroom and org.flintparticles. The result is that we know there will be no clash of names. (Tough luck if you’re from Mexico, Adobe have killed this for you by using the mx package themselves).

There is, however, an inconvenient side effect. I look at the classes in a project and see packages com, org, net, uk. I have no idea what’s inside those packages and have to open them to find out. But we put up with this because it avoids naming collisions. And we do this despite the fact that Adobe don’t do so. And despite the fact that it may confuse some users who are only used to the Adobe style.

To return to interface names. Prefixing interface names with an I causes naming collisions (e.g. IPhone interface, IPhone class). To avoid these naming collisions, I propose we shouldn’t prefix
interface names with an I. It doesn’t matter whether Adobe agree or not, any more than it matters whether they agree with our use of reverse domains for package names. What matters is that it solves a real problem of naming collisions.

Richard | 8th August 2009 at 13:22
@Jens – Since Adobe are (in my opinion correctly) wedded to backwards compatibility I wouldn’t expect them to change any existing interface names. But, as I said in the previous comment to Tink, I don’t think that prevents us changing how we name our interfaces in the future. Adobe are not always right, and when their error causes problems it’s right not to copy them.

Richard | 8th August 2009 at 13:24
@Richard You’re right. There is nothing to say that the community could not change a best practice if it finds another way would be more appropriate.

I did a quick test in Flash Builder and the way it handles the situation is pretty clever in fact. If you type in the new operator on a line, then the code hinting won’t even show you interfaces that it knows about. If you still insist and type in the name of an interface, then the IDE will show you an error on that line as soon as you save the file. It’s one of those things that has probably always been there, but I’ve never consciously looked for it.

Another thing is that in the ASDoc’s, an interface name is in italic (same practice as in Javadoc), so in this case also you should be able to differentiate interfaces from concrete implementations.

So, provided you use modern development tools and have your eyes with you, there really is no need to prefix interfaces with “I” anymore. So Richard, you’ve convinced at least one person to finally forget about I.

Jens Wegar | 8th August 2009 at 16:26
If the interface were named EventDispatcher, what would you call the existing implementation class?

Robert Penner | 23rd October 2009 at 00:18
@rob Unfortunately, since as you point out elsewhere it’s not possible to properly implement IEventDispatcher without extending EventDispatcher, it makes most sense to ditch IEventDispatcher and be honest in indicating that an event dispatcher is something that extends EventDispatcher.

If, however, it were possible to implement IEventDispatcher without using EventDispatcher then I’d call the interface EventDispatcher – this is the type that must be implemented in order to be an event dispatcher – and name the implementation according to what it is. BaseEventDispatcher, DefaultEventDispatcher, StandardEventDispatcher, IntrinsicEventDispatcher, CommonEventDispatcher, AdobeEventDispatcher – any of these seem better than the current situation, but I’m not sure which is best.

Richard | 23rd October 2009 at 08:10
The arguments for changing the current standard are not strong enough compared to the lost advantages and the confusion it causes.
So I agree with Tink.

Michiel van der Ros | 23rd October 2009 at 10:17
Adding to that: I don’t want to have to look up a class to know whether it’s an interface.
I talked to some C++ and Java developers here and they say AS should actually do MORE with prefixes, not less.

Michiel van der Ros | 23rd October 2009 at 10:19
@Michiel As I said above, going all the way and prefixing classes too clears up the confusion. I don’t like it myself but it does solve the problems caused by just prefixing interfaces. Although this does raise the question of why not do full Systems Hungarian notation.

Richard | 23rd October 2009 at 10:54

Speaking engagements

Follow me

Subscribe to this blog

Search this blog

Read articles about...

Flint particle system