1. 04 Aug, 2017 1 commit
  2. 30 Jan, 2015 1 commit
  3. 28 Oct, 2014 1 commit
  4. 08 Jul, 2014 1 commit
    • 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