Did we get OO Interfaces all wrong?

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

Recently I wrote an article on a suggested ActionScript language enhancement: implied interfaces. The idea was that, rather than having to explicitly define interfaces, they could be implied from public methods and properties of a class. This prompted a comment from someone just calling themselves “Toby” with a fascinating idea. In a nutshell that idea was: “why must we specify that a class implements an interface when it should be obvious to the compiler whether it does so or not.”

Taking Toby’s example, we have an interface IPlottable:

Now because the Flash class MovieClip has an x and y property with the same signatures as IPlottable, the compiler should treat the following code as valid:

This approach has a big advantage over the standard way of handling interfaces: IPlottable can be added to classes without needing to modify the class’ source. Of course there is a downside to this idea: runtime type checking. Consider the following modification to the last two lines above:

Here the type will not be known until runtime and at that point the class’ signature must be matched against IPlottable. The overhead of having a compiler examine the signature of a class to determine if it complies with an interface might be acceptable, but few people would be happy with such an overhead at runtime. The other option of course would be to refuse to compile the code as the type is unspecified. This seems like a cop out though.

This set me thinking: what if all (or nearly all) the overhead were pushed onto the compiler so that there was almost no impact on runtime performance. If we modify the original interface:

Here we are explicitly telling the compiler that we want it to check MovieClip against IPlottable. If compatible, everything compiles OK. At runtime, the virtual machine’s built-in reference to MovieClip is updated to add the fact that it now implements IPlottable. From that point on, everything performs as before. When the line f(IPlottable(m)); is encountered, the remains the compatibility check remains the current “does m’s type implement IPlottable”, rather than the slower “does the signature of m’s type comply with IPlottable”.

To my mind this is a far more sensible way of defining interfaces. However I’m not aware of it ever having been implemented by any OO language before. This makes me wonder: has Toby hit upon a brilliant new idea, or is there some fundamental problem with the idea that neither he nor I have spotted? If you have a view on this, please comment below.

4 thoughts on “Did we get OO Interfaces all wrong?

  1. It sounds remarkably like duck typing, and I don’t like having the interface stating the classes which implement it, I would rather use duck typing and leave that off. Your proposition is a bit like the comefrom statement.

    If you are going to have type checking then a class really ought to know which interfaces it defines.

  2. Martin,

    Thanks for the name “duck typing”. That does indeed describe Toby’s original idea.

    I’m not a fan of dynamic typing. I’ve wasted far too much time in the past hunting silly bugs caused by dynamic typing that statically typed languages just do not suffer from. In addition, dynamic languages tend to be slower due to the need to do more type checking at runtime. That is why I looked for a way to have the compiler perform the “duck test”, rather than have it occur at runtime.

    At times, I want to specify a contract that a class must comply with. In this case, standard interfaces are great as the class must explicitly commit to that contract up front. Other times though, all I want is a loose protocol, like IPlottable, that that fits the “duck type” idea. As I say though, I’d want the compiler to do the duck type checks.

  3. I am not sure about this.

    In the first example, if my class does not declare that it implements IPlottable then I might easily define one of the signatures incorrectly (or not at all) and so not conform to the interface. How is an IDE to report this to me? Also if that interface signature changes, the first I will know about it is at runtime and my program may be running incorrectly for weeks before I notice.

    In the 2nd example with the interface defining classes that implement it, what happens if the interface is in a 3rd party swc?

  4. Hey – it’s Toby (Widdowson) here. David we did meet very briefly at FOTB, but I’m obviously quite IForgettable.

    Glad to hear there is a name for this – duck typing. But since it’s a recognised concept, that makes me more confident in it’s potential benefits.

    In answer to the comments. I don’t see why this should lead to runtime errors at all. My original suggestion was that the compiler would check at compile time that methods are correctly implemented. It doesn’t have to wait til runtime to find out the bad news…

    “I would rather use duck typing and leave that off.” – that’s what I want. The option.

    Interfaces exist because of a particular issue arising from strict typing – how to tell the compiler that a method can be called on a class. It seems to me that, so long as you are telling the compiler that a method can be called on a class, which way round you do it (as in David’s idea of implementedby) is not changing the basic principle.

Comments are closed.