One of the many hotly contested items about ColdFusion in recent times that some developers have been clamoring for are the addition of interfaces to ColdFusion Components as part of the standard CFML language. At one time I was definitely in this camp myself - interfaces would indeed be a good way to make sure that components follow a given contract.

However, after much thought about the underlying implementation of them at a compile time and runtime level, I find them to be only a semantic difference to what you can already do with CFCs. While something akin to a <cfinterface> tag would make the implementation of a pseudo interface a slightly cleaner affair, the underlying implementation of interfaces in a dynamically typed language such as ColdFusion does not add much to the existing capabilities. In particular, the main purpose of an interface is to ensure that an object follows a contract, and this is technically infeasible in a dynamically typed language like ColdFusion.

A reasonable high-level comparison of dynamic languages to static languages could be summed up as a pair of safety scissors versus a razor blade. Static languages are the safety scissors - they help protect you from cutting yourself and will probably last longer, but it might take a long time to cut something. Dynamic languages are a razor blade - they are very sharp and nimble and cut through most things very quickly, but they are easy to cut yourself with if you're not careful and may have a shorter shelf-life depending on how they are used. This comparison is not valid for all languages, but works well for comparing a dynamically typed language such as ColdFusion and Python to a statically typed language like Java.

ColdFusion is dynamically typed because you don't have to specify the primitive data type of variables when they are created, as the CFML runtime examines a given variable and takes care of that for you. In general, this allows you, the developer, to concentrate on getting things done rather than managing each variable you create. Statically typed languages such as Java typically require the developer to declare the data type for all variables, and provide compile-time checking to make sure all variables and method signatures are typed correctly.

While it is generally more time-consuming to program in statically typed languages, it does provide more type safety and at a micro level has greater performance. One of the performance advantages would be that because the runtime can already be assured of which data type each variable contains, fewer CPU cycles are used introspecting data and turning it into code that a CPU can understand. There are plenty of other advantages and disadvantages between the two types of languages as well that are beyond the scope of this article.

When I find a need for an interface in ColdFusion, I essentially create my own pseudo interfaces that at least provide runtime checking in case an inheriting object's method is called. It's not necessarily the best solution, but it does at least offer some sort of contract that an inheriting object can be tied to, mostly for documentation purposes. I've seen several other people do it as well, but it looks something like this:

foobar/Foo.cfc

<cfcomponent hint="Interface for foo">
    <cffunction name="init" returntype="any">
       <return this />
    </cffunction>

    <cffunction name="implementThis" returntype="any">
       <cfthrow message="foobar.Foo: implementThis() must be implemented">
    </cffunction>
</cfcomponent>

foobar/Bar.cfc

<cfcomponent hint="Provides foobar functionality">
    <cffunction name="init" returntype="any">
       <return this />
    </cffunction>

    <cffunction name="implementThis" returntype="any">
       <cfreturn true />
    </cffunction>
</cfcomponent>

These are just some quick pseudo-code examples coded for brevity, but you get the idea.

As I started to question the usefulness of interfaces in ColdFusion in light of the way a lot of people are already doing them, I began to realize that the implementation of an interface tag or attribute to CFCs would not really offer any technical advantages at a runtime level, so largely their implementation is only a semantic difference.

In Java, one of the main advantages to using an interface is that it does compile-time checking to make sure that classes implementing interfaces follow the contract dictated by the interface as well as the full method signature of required arguments. As ColdFusion is a dynamically typed language, there really isn't a good way to do compile-time checking of interfaces. It is also impossible to do a full method signature of an object at compile time because of the nature of dynamically typing - the full signature of an object can change at runtime because of the flexibility inherent in dynamically typed languages.

One of the reasons I decided to write about this is that it's a subject that has been debated heavily in the community as a needed feature for the upcoming ColdFusion 8, currently code-named Scorpio. BlueDragon 7, currently in beta, does include an implementation of interfaces. I wrote a shortened preview version of this article on my blog, which drew some valuable dialog, in particular from Vince Bonfanti, the CEO of New Atlanta.

Vince discussed the nature in which interfaces are implemented in BlueDragon, which I think are technically sound and the way I would personally attempt to add interfaces into a dynamically typed language. However, any sort of interface implementation in a dynamic language such as ColdFusion are only semantics because you can't check the full method signature of an object until runtime, rather than at compile time as you can with static languages. While I do concur that the syntax is cleaner than in the example I provided earlier, I disagree in principle that it's a true interface. A counter-example I provided is how many developers using the open language Python have proposed interfaces over the years, but it's never been implemented for the reasons I've cited as well as due to disagreements in the syntax of its proposed implementation, among other reasons.

Summary
Due to the nature of dynamically typed languages, the implementation of interfaces in ColdFusion would not prevent someone from breaking the contract of an interface at runtime. Any implementation of interfaces in the CFML language would essentially only represent a difference in semantics to other ways already available to implement interface-like objects without providing the safety that interfaces should provide. There are bigger problems to solve and better features to implement in the next version of ColdFusion than interfaces.