Modularization and Reuse

Operator-libraries in HL3 are a powerful mechanism to enable reuse and modularization of operator-trees. In combination with the abstraction mechanism provided by CombinedOperators and OperatorExtractors it is very easy to define high-level building-blocks by encapsulating operator-trees. These building blocks can be stored into an operator-library and later be reused in other engines that also need the functionality provided by the collection of building-blocks.

Limitations

Even though HL3 has OperatorLibraries for modularization and CombinedOperators for abstraction there is a limiting factor that restricts reuse of operator-trees (also see #107). The problem is that using an operator from the library means copying the definition into the executable operator-tree. This means that when the definition of an operator in a module changes is also has to be manually changed in all existing operator-graphs that contain copies of that operator. Instead of 'code-reuse' what actually happens is 'code-duplication'.

Ideas

Import-Operator

One simple and rather straight-forward idea to overcome the code-duplication problem is to create an 'import-operator that loads operators from an operator-library into the scope-tree at runtime. Instead of dragging the operator from the operator-library into the operator-graph at 'design-time' one would use an import-operator as one of the first steps in the operator-graph and define which operator-library file should be loaded. At the points where one of the library-operators should be used an OperatorExtractor can be used as a placeholder for the appropriator operator in the library. The OperatorExtractor can be easily configured with the name of the library-operator.

To prevent problems of duplicate operator-names in different operator-libraries it would be easy to add a namespace mechanism. We could just use a different name prefix for the injected operators of each operator-library.