Based on experience with other languages, we make these basic choices:
Every class has an interface
Interfaces, as used by Java, turn out to be a very clear mechanism. However,
it can sometimes lead to repeating the signature definition of a method
several times: In the interface and with each method that implements it.
We need to find ways to avoid that when it is not needed. And still make sure
the compiler produces an error when you do something wrong.
In Zimbu every class implicitly defines an interface. This means that when you define
a class, with all its methods and attributes, this results in both an implementation
and an interface definition. The name of the interface is equal to the class name
with ".I" appended. Thus the class Border defines the interface Border.I.
An explanation and supporting arguments are on the Reference Type page.
One of the basic mechanisms of modern programming languages is
inheritance: define a basic class and then derive subclasses from it.
We want to support this in Zimbu.
The devil is in the details. We need to help the programmer to avoid
mistakes. How this is done is discussed on the Abstract and Virtual page.
Composition of Interfaces and Implementations
Part of the implementation of a class is often the same as what is used in
other classes. We don't want to write the same code twice, for obvious
reasons. How do we share parts of one class with another class?
There are many mechanisms available. Some of the most well known are:
We also support composition with some extra mechanisms to avoid bulky glue code.
This is discussed on the Class composition page. This talks about the choice to
use the PIECE definition, with INCLUDE statements and statements to connect
and wrap methods. Together this reduces duplication and defines a mechanism
for code reuse that is simple to understand, efficient and avoids mistakes.
There are many choices to be made. A few more on the class details page.
The resulting building blocks are: