08. Meeting Minutes (09.05.2018)

Attendees: Samer, Daryl, Xiaoli, Nazim

Date: Tuesday May 09, 2018

Time: 2:00PM --> 3:00PM

Discussion

• Discussion about getting rid of the extensible class hierarchy structure found in OMR (how the connectors and static polymorphism work). Xiaoli said it is confusing and it obliges developers to use the concrete(TR) class of a hierarchy whereas the default way of using polymorphism is to use the base class (OMR) of the hierarchy. However, we all agreed that our proposition at the moment does not involve to change that structure.
• Virtualizing all functions in a class is not a good idea because in that case all new functions declared in language namespaces will have to be declared in the base class (in the OMR namespace) of a hierarchy and added to the OMR public source code by a pull request(PR).
  • Consider an example where OMR is used by Java language developers. Developers extend OMR with a Java namespace where 100 new functions are implemented. If our plan is to virtualize all functions, the 100 new functions added by Java developers will have to be declared as pure virtual in the OMR namespace and a PR have to be issued by the Java developers to the OMR Git repository. After that, Ruby developers would added another 100 functions and go through the same process as Java developers. Now OMR namespace has 200 pure virtual functions that are not used in the OMR source code. Daryl remarked that this is referred to as a Kitchen Sink design.
• One idea is to virtualize API functions only; that is functions that are expected to be extended by developers. In that case, all the functions in OMR have to be inspected and a decision would be made if each function is part of the API highlighted to language developers or not. OMRStatistics plays an important role in this objective since it helps distinguish API functions by narrowing down the set of inspected functions to the set of overridden functions only (instead of all functions in OMR).

Objective

Our plan is to change the polymorphism in OMR from static polymorphism to a hybrid implementation of static and dynamic polymorphism.

• Static polymorphism and the use of self() is for functions that are used inside OMR project only and will keep using static polymorphism in order not to impact performance.
• Dynamic polymorphism for functions that are intended to be extended by language developers, that is the API of OMR. This would also be a good way to mark the API of OMR with the virtual keyword.

Adding a function to the API

With this change, adding functions to the API would become a deliberate decision. If a language developer wants to override a non-virtual function in OMR, the developer can do one of the following actions:

• Change function to virtual in OMR, submit a PR to the OMR Github repository to make it an official part of the API.
• Change function to virtual and not submit a PR to the OMR repo. In that case, every time the OMR repo is updated, the developer would have to remake their changes.
• Use static polymorphism to extend that specific function, and use self() where necessary.

Evaluation of Proposition

Advantages

• Having a better mechanism to describe extension points and API (using virtual keyword).
• Making the code look cleaner since self() is not used by language developers.
• Having pure virtual functions (obliging user developers to implement some functions).

Disadvantages

• Some functions are already using virtual. Hence, not only API functions will be using the virtual keyword. Therefore, this is not the ideal way to describe the API.
• If developers are expected not to use self() and hence are not educated and warned about its functionality (which is the convenience of virtualizing API functions), developers might mistakenly use functions from the OMR namespace and hence the library will behave differently.

Controversial

The use case described above (adding a functionality to the API) is a pro and con of our proposition. It is good because this means adding a function to our API is now a deliberate decision. However, it is bad because if we do not accept that PR for any reason (for example if a user developer wants to virtualize a function that is used enough times that virtualizing it might effect the performance), user developers will have to keep applying their changes with every update; which might drive them away from using OMR.