Summary
I believe interfaces are important enough to warrant a categorization of IOPL's (Interface Oriented Programming Languages). Here's my attempt to describe them.

Advertisement

The following is not so much a definition of an interface oriented programmign language, but my first attempt to describe them.

Interface Oriented Programming Languages

An interface oriented programming language (IOPL) is similar to an object oriented programming language (OOPL) but differs in one subtle but very significant way:
in an IOPL dynamic function dispatch occurs in the interface, not in the class itself.
This means there are no "virtual" or "abstract" functions.
As a result of this a class will always the same behaviour, no matter how it is inherited. This is a substantial deviatiaion from an OOPL where behaviour of a class can change depending on how it is inherited.

In many OOPL's objects contain a pointer to a function table for dispatching virtual functions at runtime. In an IOPL, a function table pointer would be associated with an interface reference. So in an IOPL the abstraction penalty (in space and speed) occurs only when using an object in a polymorphic context. This can be significant in some designs where dynamic function dispatching is required rarely.

Another benefit of the IOPL approach is that classes can be more easily
optimized by a compiler since intra-method calls (calls from one member function to another), can be resolved at compile-time.

Discussion

Do you think that IOPL warrants a categorization, and if so how would you improve upon the description?

I think it's a good idea for a categorization. It might need fleshing out a bit, with reference to what makes an object-oriented language object-oriented.

>An interface oriented programming language (IOPL) is similar to an object oriented programming language (OOPL) but differs in one subtle but very significant way: in an IOPL dynamic function dispatch occurs in the interface, not in the class itself.

My response: It sounds like a definition by implementation. I wouldn't use the same thing for Object Oriented programming languages, saying that what defines the class of language is the dynamic dispatch mechanism. In fact, I don't even think inheritance is required for a language to be OO. An OO language is just one which lets you express things in terms of objects. And in that case, IOPL is probably a subset of OOPL. So, what principle does IOPL really aim to capture that is missing from OO?

(I'd rather hear about the differences it makes in allowing good abstractions and designs, or other software engineering benefits of using the language. Because to me, that is what necessitates a new language. Describing things in a new and more convenient way.)

>This means there are no "virtual" or "abstract" functions.

I think the opposite: EVERY interface function is virtual or abstract, because it has no immediate implementation.

>As a result of this a class will always the same behaviour, no matter how it is inherited. This is a substantial deviatiaion from an OOPL where behaviour of a class can change depending on how it is inherited.

If the behaviour can't change at all with inheritance, how can subclassing be useful - because you then can't change the implementation of anything that is inherited, right?

I guess that you want to say "the behaviour is the same, in that they both must satisfy exactly the interface specification". This might leave them some room to be different after subclassing. I think it's also a significant point here that the amount of variation allowed in subclasses is really going to be dependent on what the interface can and does specify, and the language can enforce.

In a language like Java, the interface specification is quite minimal, i.e. that any object O subclassing P has all the method signatures of object P. And so the behaviour of objects O and P can be different in many many ways...

>In many OOPL's objects contain a pointer to a function table for dispatching virtual functions at runtime. In an IOPL, a function table pointer would be associated with an interface reference. So in an IOPL the abstraction penalty (in space and speed) occurs only when using an object in a polymorphic context. This can be significant in some designs where dynamic function dispatching is required rarely.

I.e. they're easier to write good compilers for?

>Another benefit of the IOPL approach is that classes can be more easily optimized by a compiler since intra-method calls (calls from one member function to another), can be resolved at compile-time.

possible correction: intra-object calls? I don't understand this bit... but it must have something to do with the difference in dispatching.

I think it's a good idea for a categorization. It might need fleshing out a bit, with reference to what makes an object-oriented language object-oriented.

>An interface oriented programming language (IOPL) is similar to an object oriented programming language (OOPL) but differs in one subtle but very significant way: in an IOPL dynamic function dispatch occurs in the interface, not in the class itself.

My response: It sounds like a definition by implementation. I wouldn't use the same thing for Object Oriented programming languages, saying that what defines the class of language is the dynamic dispatch mechanism. In fact, I don't even think inheritance is required for a language to be OO. An OO language is just one which lets you express things in terms of objects. And in that case, IOPL is probably a subset of OOPL. So, what principle does IOPL really aim to capture that is missing from OO?

(I'd rather hear about the differences it makes in allowing good abstractions and designs, or other software engineering benefits of using the language. Because to me, that is what necessitates a new language. Describing things in a new and more convenient/powerful way.)

>This means there are no "virtual" or "abstract" functions.

I think the opposite: EVERY interface function is virtual or abstract, because it has no immediate implementation.

>As a result of this a class will always the same behaviour, no matter how it is inherited. This is a substantial deviatiaion from an OOPL where behaviour of a class can change depending on how it is inherited.

If the behaviour can't change at all with inheritance, how can subclassing be useful - because you then can't change the implementation of anything that is inherited, right?

I guess that you want to say "the behaviour is the same, in that they both must satisfy exactly the interface specification". This might leave them some room to be different after subclassing. I think it's also a significant point here that the amount of variation allowed in subclasses is really going to be dependent on what the interface can and does specify, and the language can enforce.

In a language like Java, the interface specification is quite minimal, i.e. that any object O subclassing P has all the method signatures of object P. And so the behaviour of objects O and P can be different in many many ways...

>In many OOPL's objects contain a pointer to a function table for dispatching virtual functions at runtime. In an IOPL, a function table pointer would be associated with an interface reference. So in an IOPL the abstraction penalty (in space and speed) occurs only when using an object in a polymorphic context. This can be significant in some designs where dynamic function dispatching is required rarely.

I.e. they're easier to write good compilers for?

>Another benefit of the IOPL approach is that classes can be more easily optimized by a compiler since intra-method calls (calls from one member function to another), can be resolved at compile-time.

possible correction: intra-object calls? I don't understand this bit... but it must have something to do with the difference in dispatching.

It seems that what you are suggesting is basically to make the virtual pointer table a type unto itself --- a polymorphic type. This is quite similar to Java's interfaces, and Objective-C's protocols. One thing I like about this approach is that polymorphism and inheritance are orthogonal to one another.

Interestingly, you can implement this approach quite easily in a non-OO language with a simple preprocessor. For example, I have <a href="http://www.maniacalextent.com/blog/?p=5">blogged</a> about using 'interfaces' in Fortran code, of all languages.

I'm not sure if this approach warrants an entirely new classification. Afterall, a protocol/interface is nothing more than a specialized class, one in which there are no instance variables. You can always implement IOP in an OO language by introducing interface classes, so I would argue that IOP is just a specialized case of OOP.

Regarding the blog: I think a code example (even pseudo-code) of definitions and use, could clarify, and make comparisions to existing features easier to make, because I have a hard time understanding what you mean, here.

> So, what principle does> IOPL really aim to capture that is missing from OO?

I guess the fact that an object will always behave the same no matter how it is an inherited.

> (I'd rather hear about the differences it makes in> allowing good abstractions and designs, or other software> engineering benefits of using the language. Because to me,> that is what necessitates a new language. Describing> things in a new and more convenient/powerful way.)

Good idea, I'll try to come up with some examples.

> >This means there are no "virtual" or "abstract"> functions.> > I think the opposite: EVERY interface function is virtual> or abstract, because it has no immediate implementation.

It would be more correct for me to say then that there are no virtual function inside of objects. However the idea of virtual and abstract imply overriding. From the point of view of an object, it doesn't override anything.

> If the behaviour can't change at all with inheritance, how> can subclassing be useful - because you then can't change> the implementation of anything that is inherited, right?

If you want to achieve the kind of effect that the following C++ code would give you:

class Pet { public: virtual string make_sound() = 0;};

class Cat { public: string make_sound() { return "meow"; }};

class Dog : Pet { public: string make_sound() { return "woof"; }};

You could equivalently achieve that with the following:

interface Pet { signature { string make_sound(); }};

class Cat { public: string make_sound() { return "meow"; }};

class Dog { public: string make_sound() { return "woof"; }};

Does that answer your question?

> I guess that you want to say "the behaviour is the same,> in that they both must satisfy exactly the interface> specification". This might leave them some room to be> different after subclassing.

I am not sure I follow.

> I think it's also a> significant point here that the amount of variation> allowed in subclasses is really going to be dependent on> what the interface can and does specify, and the language> can enforce.

Again, I don't follow.

> In a language like Java, the interface specification is> quite minimal, i.e. that any object O subclassing P has> all the method signatures of object P. And so the> behaviour of objects O and P can be different in many many> ways...

I think I understand where we are having a disconnect. What I am trying to say is that virtual functions cause an objects behaviour to change depending on how it is inherited.

> I.e. they're easier to write good compilers for?

I believe so.

> >Another benefit of the IOPL approach is that classes can> be more easily optimized by a compiler since intra-method> calls (calls from one member function to another), can be> resolved at compile-time.> > possible correction: intra-object calls? I don't> understand this bit... but it must have something to do> with the difference in dispatching.

> It seems that what you are suggesting is basically to make> the virtual pointer table a type unto itself --- a> polymorphic type.

That is a fair assesment, though the pointer table has to be bundled with an object pointer.

> This is quite similar to Java's> interfaces, and Objective-C's protocols. One thing I like> about this approach is that polymorphism and inheritance> are orthogonal to one another.

Nicely put, thanks.

> Interestingly, you can implement this approach quite> easily in a non-OO language with a simple preprocessor.> For example, I have <a> href="http://www.maniacalextent.com/blog/?p=5">blogged</a>> about using 'interfaces' in Fortran code, of all> languages.

> I'm not sure if this approach warrants an entirely new> classification. Afterall, a protocol/interface is nothing> more than a specialized class, one in which there are no> instance variables. >> You can always implement IOP in an OO> language by introducing interface classes, so I would> argue that IOP is just a specialized case of OOP.

In C++ however you can't implement interfaces without using virtual functions, or some really ardurous table initialization code. The idea of an IOP, is to be able to use objects polymorphically without virtual functions.

> Regarding the blog: I think a code example (even> pseudo-code) of definitions and use, could clarify, and> make comparisions to existing features easier to make,> because I have a hard time understanding what you mean,> here.

> > Regarding the blog: I think a code example (even> > pseudo-code) of definitions and use, could clarify, and> > make comparisions to existing features easier to make,> > because I have a hard time understanding what you mean,> > here.> > Good point, thanks. Anything specific which is> particularly unclear?

> > Regarding the blog: I think a code example (even> > pseudo-code) of definitions and use, could clarify, and> > make comparisions to existing features easier to make,> > because I have a hard time understanding what you mean,> > here.> > Good point, thanks. Anything specific which is> particularly unclear?

Well, to take what you write in your blog:

"in an IOPL dynamic function dispatch occurs in the interface, not in the class itself."

Here, it's not clear what you mean. An "interface" can occur in many forms; the member functions of a class or object (and potentially free functions that takes the object as a parameter), may be considered a class' or object's interface. Then you may have a subsystem interface, perhaps consisting of several classes. Another interface may be defined in terms of a webservice, and so on. However, from your previous writings on interfaces, I assume you mean something like Java's "interface" keyword.

From this standpoint, I still have a hard time deciphering what you mean by the quote above. You have a code example with Pet interface/class, and Cat and Dog classes. Perhaps you could have completed this one, by showing how this may be used, as well?

Hm, I think I may know what you're getting at. In earlier blogs, you've described a feature of Heron, where one may use interfaces, that work similar to "duck typing" or "concepts", but unlike concepts or constrained genericity in languages like C# or Java, these may be bound at compile-time or run-time, depending on the information that is available. In other words, similar to C++ templates (or better, "concepts", but as it doesn't exist in C++ (yet), I use templates as an example), but being able to bind also at run-time. Is that right?

/* I think it's a good idea for a categorization. It might need fleshing out a bit, with reference to what makes an object-oriented language object-oriented. ... I don't even think inheritance is required for a language to be OO. An OO language is just one which lets you express things in terms of objects.*/

There were already languages that used objects to organize things without inheritence before OOP caught fire. For instance, Ada originally worked this way. When programmers create classes in C++ that very clearly aren't going to be sub-classed, it's usually referred to as "object-based programming." There are different concerns for object-based programming than OOP.

I think CDiggins is referring to OOP as being able to pretend a derived class is the base class. That is, if A extends B, getting a bunch of B's together using them only according to the B interface, even though some of them are As, and some may even be Qs, and getting A and Q-specific behavior.

This is usually implemented in a way that the compiler doesn't know if any particular B is a B, or an A, or a Q until run-time (or rather, *after* you've called the method).

IOP, OTOH, would be a technique of telling the compiler that A and Q are accessible using the same interface, but without going through B. Instead, the compiler would have to determine at compile time what class the object truly belonged to (IOW, in order to call the method, the compiler must be able to determine if it's an A or a C).

This does allow for a more effecient calling mechanism, but it also requires either a smarter comiler than normal, or keeping more information around to know the real class of object being used.

/* I'd rather hear about the differences it makes in allowing good abstractions and designs, or other software engineering benefits of using the language.*/

> > Regarding the blog: I think a code example (even> > pseudo-code) of definitions and use, could clarify, and> > make comparisions to existing features easier to make,> > because I have a hard time understanding what you mean,> > here.> > Good point, thanks. Anything specific which is> particularly unclear?

Are you saying that in IOPL the method used is determined at compile time based on the reference type vs. the method being determined by the runtime type of the Object?

I believe the above is correct. With that assumption, the next question is whether the methodology is based on how the method is called or how it is defined (ala Java)? If it is the latter, it's an interesting idea but it seems incompatible with OO code as the Object's behavior depends on the context it is called in. Basically, I could override a method and you can thwart me by calling the parent version, even if it is no longer compatible with leaf class definition.