The Artima Developer Community
Sponsored Link

Weblogs Forum
What's in a name ... Traits versus Interfaces

4 replies on 1 page. Most recent reply: Jan 22, 2006 2:52 PM by Howard Lovatt

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 4 replies on 1 page
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

What's in a name ... Traits versus Interfaces (View in Weblogs)
Posted: Jan 21, 2006 9:57 AM
Reply to this message Reply
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.


Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Traits, Interfaces, or something new... Posted: Jan 21, 2006 10:33 AM
Reply to this message Reply
Convention would appear to suggest interfaces are implementationless (and probably stateless), and classes are interfaces plus implementation and state.

So if you want something in between it would be best to choose a new denomination: something cognate, such as type, group, form (thesaurus time)...

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Traits, Interfaces, or something new... Posted: Jan 21, 2006 1:10 PM
Reply to this message Reply
> Convention would appear to suggest interfaces are
> implementationless (and probably stateless), and
> classes are interfaces plus implementation and
> state.
>
> So if you want something in between it would be best to
> choose a new denomination: something cognate, such as
> type, group, form (thesaurus time)...

Traits do have implementation. So if one views an interface as being implementationless, then perhaps 'trait' is a closer match.

IMHO it is more significant that an interface has no state than having no implementation. If you introduce defined functions into an interface, it has less overall effect to a language than if you introduce state. For example one could add the notion of extension to Java interfaces with virtually no side effect to the rest of the language, and minimal changes to a Java compiler. Introducing state into an interface on the other hand would have much more severe repercussions throughout the language specification and implementation.

I am however still partial to the name "interface". I am hoping that the Heron interface can be easily explained and defined as a Java-like interface with the introduction of contract verification, optional structural subtyping, and extension functions.

A couple of other names for the construct which I have considered: signature or contract.

Kresimir Cosic

Posts: 6
Nickname: kreso
Registered: Jan, 2006

Re: Traits, Interfaces, or something new... Posted: Jan 22, 2006 1:11 PM
Reply to this message Reply
To me, names don't matter, anything is ok, but if I was choosing:
interface, trait - best
signature, contract - not so good, might be ambigous

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: What's in a name ... Traits versus Interfaces Posted: Jan 22, 2006 2:52 PM
Reply to this message Reply
> The term "inner" was suggested by <a
> href="http://www.artima.com/forums/flat.jsp?forum=106&threa
> d=142895">Howard Lovatt</a>.

Thanks for the acknowledgement but without clicking through the link you gave it sounds like I invented the term. As you know, but other new to the discussion might not, the term inner comes from Simula 67 (the original OO language).

Flat View: This topic has 4 replies on 1 page
Topic: What if Constant Values were also valid Types? Previous Topic   Next Topic Topic: What's up with Diggins?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use