Free cookie consent management tool by TermsFeed Policy Generator

Changes between Version 1 and Version 2 of ModularizationAndReuseWithOperatorLibraries


Ignore:
Timestamp:
04/20/08 12:46:43 (17 years ago)
Author:
gkronber
Comment:

added description of import-operator idea

Legend:

Unmodified
Added
Removed
Modified

  • ModularizationAndReuseWithOperatorLibraries

    v1 v2  
    77
    88 = Ideas =
    9  == Using-Operator ==
     9 == Import-Operator ==
     10One 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.
    1011
     12To 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.