The following topics are meant as collections of design ideas, with the purpose of refining them into concrete design proposals.

Reactor classes can be parameterized with type parameters as follows:

reactor Foo<S, T> {
    input:S;
    output:T;
}

We could like to combine generics with type constraints of the form S extends Bar, where Bar refers to a reactor class or interface. The meaning of extending or implementing a reactor class will mean something slightly different from what this means in the target language -- even if it features object orientation (OO).

While initially being tempted to distinguish interfaces from implementations, in an effort to promote simplicity, we (at least for the moment) propose not to. Only in case reactions and their signatures would be part of an interface and thus should be declared (without supplying an implementation) would there be a material difference between an interface and its implementation. Making reactions and their causality interfaces part of the reactor could prove useful, but it introduces a number of complications:

• ...

• A reactor can extend multiple base classes;
• Reactions are inherited in the order of declaration; and
• Equally-named ports and actions between subclass and superclass must also be equally typed.