Interfaces and Overriding in LF Inheritance

[mkhubaibumer]

Interface

LF provides the basic semantics and very limited functionality for Inheritance I believe LF can extend the feature set around Inheritance for example Interfaces come to mind to restrict certain patterns.
I believe that interfaces are a required feature as the LF matures. Interface also provides extensive way for the user to develop their own plugins as the inputs and outputs are mandated by the Interface.

Overriding

If Parent Reactor defines reactor for certain trigger, the Child should be able to Override the effect if required and with the named reactions I think Overriding also becomes a viable candidate for expansion.
With the current semantics the user can overwrite the output, however, this does not feel like a good approach to follow.

[edwardalee]

Two questions:

1. What is the difference between an interface and a reactor with no reactions? If there is no difference, why do we need a separate concept?

2. If named reactions are supported in an OO target like Cpp, then I presume that overriding reactions would be easily done in the target language. Perhaps the same effect could be achieved in the C target, but I wouldn't give this highest priority. Do you have a compelling use case?

[mkhubaibumer]

@edwardalee

1. The difference would be that with the current semantics, providing the reactions for ports is optional which allows the child reactor to break the behavioural enforcement. Thus the child can opt to not provide reactions for any port. With interface we enforce that the Child has to provide reactions for ports with no reactions to conform with the required behaviour. This will allow us to customise/replace modules and opens up avenues for plugins.
   One example for this would be if we use a HashTable in some component and we are using CuckooHash but the user wants us to use their own HashTable Implementation, maybe linear probing, we provide an Interface called AbstractHashTable and they can inherit it and if Interface is inherently supported by LF they will need to provide reactions for the ports defined in AbstractHashTable. By doing this they can simply swap in their own implementation of HashTable without changing any of the other components.

2. Overriding is one of the aspect that we feel is now possible with named reactions. The current way is kind of counterintuitive. There should be a very clear and definitive way to either handle effects for both parent reaction and child reaction or calling parent reaction should be explicit and child reactor should override the parent reaction.
   With that being said I don't think overriding is as important as interfaces. Its a good to have feature as it provides very clear intent.

[cmnrd]

@edwardalee with respect to 1., I would argue that a sensible reactor interface also includes the dependency information. Only if we know the internal structure of the reactor interface (i.e. we can draw a diagram for it), we can seamlessly exchange implementations without recompilation.

I am not sure if we really need virtual inheritance and abstract interfaces in LF though. Reactors are not equivalent to classes in OO languages and we shouldn't confuse the concepts. I see several challenges with supporting reactor interfaces natively in LF. Since reactions contain arbitrary code, the problem could be solved quite as well in the reaction bodies. After all the target languages already have the necessary concepts (well, except for C, but there it can be emulated).

For the hash table use case that @mkhubaibumer provided, an (arguably simpler) alternative would be to define the AbstractHashTable interface in the target language and then parameterize the reactor with a concrete object implementing this interface. So the reactor implementation would be fixed and the reactions would call the methods of the interface. By providing concrete implementations of the interfaces when instantiating the reactor, the internal behaviour can be changed. This would have the additional benefit that users implementing the interface do not need to understand the reactor semantics.