Summary
For the umpteenth time I am changing my name about how to name traits/interfaces in Heron.

---

Advertisement

For those new to the discussions, there is a special kind of type in Heron which is like a Java interface. I was calling it a trait for a while, because ... well because it looked like a trait, and shared the characteristic of allowing fully defined functions. When it comes down to it, the construct is equidistant from both interfaces and traits. I am now thinking that because more people are familiar with what an interface is, it would be easier to call it a trait, and explain it has having more features than a Java interface. Here is an example of an interface using the latest syntax:

interface Array[type T]
{
  requires
  {
    def count() : uint;
    def _subscript(uint n) : T& {
      pre(n < count());
      inner;
    }
  }
}

interface Stack[type T]
{
  inherits
  {
    Array[T];
  }
  requires
  {
    def push(T x) {
      uint old = count();
      inner;
      post(count() == old + 1);
    }
    def pop() {
      uint old = count();
      pre(!is_empty());
      inner;
      post(count() == old - 1);
    }
    def top() : T& {
      pre(!is_empty());
      inner;
    }
  }
  extension
  {
    def is_empty() : bool {
      return count() == 0;
    }
    def clear() {
      while (!is_empty()) {
        pop();
      };
    }
    def dup() {
      push(top());
    }
    def reverse() {
      if (count() < 1) return;
      int max = count() - 1;
      uint n = count() / 2;
      for_each (i, range(0,n-1)) {     
        swap_elements(i, max - i);
      };
    }
    def swap_elements(uint i, uint j) {
      T tmp = _subscript(i);
      _subscript(i) = _subscript(j);
      _subscript(j) = tmp;
    }
  }
}

An interface is a stateless type made up of three optional sections: inherits, requires, and extension (was previously called 'public'). An interface variable can refer to a value of any type (class or other interface reference) which "implements" the interface. An object implements an interface if it provides implementations of the functions which are listed in the requires section of an interface. A class can optionally declare that it implements an interface, in which case it inherits the extension functions. That is the first difference between Java interfaces and Heron interfaces. The next big difference, is that "required" functions can be redefined by an interface. If the interface chooses to pass the function to the object, it does so through the "inner" keyword (previously named "override").

The principal reason for allowing required function redefintions is so that preconditions and postconditions can be verified (using the pre / post macros). The innert keyword is equivalent to writing: result = super->method_name(method_args) if the function is non-void or simply super->method_name(method_args) otherwise.

I hope this makes more sense than the older syntax and explanations. Any feedback would be appreciated as usual.

Acknowledgements

The term "inner" was suggested by Howard Lovatt. The inclusion of optional implements clauses in classes, was suggested by many people but the straw which broke the camel's back was due to Kresimir Cosic's lengthy and patient discussion. Peter Grogono, pointed out that "traits" was perhaps not the best choice of terms. My apologies if I overlooked anyone else's contribution. Many people have contributed valuable input to various discussions on Heron, which is much appreciated.

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

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.