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:
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.
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)...
> 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.
> 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).