Sponsored Link •
I believe interfaces are important enough to warrant a categorization of IOPL's (Interface Oriented Programming Languages). Here's my attempt to describe them.
The following is not so much a definition of an interface oriented programmign language, but my first attempt to describe them.
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.
Do you think that IOPL warrants a categorization, and if so how would you improve upon the description?
|Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.|