Skip to content
  • David Thompson's avatar
    Use the attribute system to specify operators. · da25ac93
    David Thompson authored
    Remove the `smtk/model/{Parameter,OperatorResult}` classes.
    They are replaced by adding a `specification()` method to
    the `Operator` class that returns an `AttributePtr` (typedef'd
    to `OperatorSpecification`). The `OperatorResult` class is
    also replaced by an `AttributePtr`.
    
    The attributes and their definitions are held by an
    attribute `Manager` owned by the `Bridge` whose model
    entities the operators can have as operands.
    
    Since the attribute system will be used for operators,
    it will be possible to determine operator names and
    parameters without instantiating an operator. (Instead,
    the attribute manager for the bridge can be asked for
    definitions.) Because of this, `Operator`s now use the
    same auto-init utilities as the `Bridge` classes.
    Upon an operator's static initialization, it registers
    itself with the proper subclass of `smtk::model::Bridge`,
    providing its name, a constructor function, and an XML
    definition of its parameters and another definition of
    its result values.
    When an instance of a Bridge subclass is constructed,
    each registered operator's XML definition is loaded into
    the bridge's attribute manager.
    Thus, bridges no longer keep a list of Operator instances;
    instead their attribute manager tracks available definitions.
    
    Operators now have a "specification" that is an AttributePtr
    specifying parameter values.
    The specification is null by default but can be set to an
    attribute with the proper definition (matching the one in the bridge's
    attribute manager).
    
    ImportJSON and ExportJSON provide methods for transporting attribute
    definitions.
    Since the XML reader does not provide a list of
    the toplevel attributes it reads, the JSON
    we export/import must store a copy of attribute
    name alongside the XML.
    
    This commit also adds smtkTypeMacro() to a large number
    of smtk::attribute classes so that templated methods operating
    on subclasses of Item and ItemDefinition can refer to
    shared pointers more easily.
    
    This commit makes the Bridge class's `operatorManager()`
    attribute manager held by pointer rather than by value.
    Because subclasses of DefaultBridge (like the TestForwardingBridge
    in the unitDefaultBridge test) are constructed by calling all
    subclass constructors, they would being initialized with the
    wrong static list of operator constructors if the manager
    was held by value. Now, when each Bridge
    subclass calls `initializeOperatorManager()` in its constructor,
    any previous subclass initialization is blown away by deleting
    the old `operatorManager()` and constructing a new one before
    populating it. It would be nice to have a `reset()` method on
    attribute::Manager. Sigh.
    
    Finally, this adds some helper methods to bridges and operators
    for obtaining the class name of an instance. The tests use this
    to aid in debugging.
    
    Silence silly shiboken signals: ignore warnings generated by
    shiboken-generated-code... at least for GNU and clang C++ compilers.
    
    A CMake function named smtk_operator_xml() is installed so that
    external projects (namely CMB) can use it. This function encodes
    an XML file as a C++ string for use in associating an `Operator`'s
    C++ implementation with its XML definition.
    da25ac93