-
Notifications
You must be signed in to change notification settings - Fork 0
Design_api
A design exists relative to a design space, and it consists of a set of parameter ID-to-value mappings. There are two main operations that are relevant for designs.
- Getting the value of a parameter.
- Setting the value of a parameter.
In InPUT4j, designs are represented by the IDesign interface.
This operation produces the value that is mapped to a specific ID in the design.
Trying to get the value for a parameter ID that does not exist in the design is legal. A [null][Terms_null] value should be returned in that case.
In InPUT4j, this operation is supported by the getValue method.
This operation associates a specific parameter ID with a new value. The value must match the definition of the corresponding parameter.
Setting a value that does not match the parameter definition is illegal.
Setting a value for a parameter ID that does not exist in the design is illegal.
In InPUT4j, this operation is supported by the setValue method.
This operation prevents direct applications of the set value operation. Trying to set a parameter to a new value for a read-only design is illegal.
Note that the effect of the read-only status is rather specific and limited. Associating parameter IDs to new values is not illegal in itself. In particular, extending the scope of a design severely weakens the significance of the read-only status of a design.
In InPUT4j, this operation is supported by the setReadOnly method.
A design can also be created read-only using the overloaded
nextDesign method of IDesignSpace.
This operation produces a design that is the union of two designs. That is, the set of ID-to-value mappings of one design is extended to include the mappings of another design.
Extending a design with itself is legal.
Extending a design with an overlapping design is legal. That is, a design can extend another design even if one or more parameter IDs exist in both designs. The existing parameter takes precedence in that case, and the parameter in the extending design is ignored.
Circular extensions are invalid.
Extending a design does not alter the set of supported IDs, even when new IDs become valid for the resulting design.
Extending a read-only design is legal.
Note that the ability to extend a design interacts with the ability to mark a design as read-only.
In InPUT4j, this operation is supported by the extendScope method.
This operation produces the set of the IDs of all the parameters that make up the design.
Note that a design also contains array elements. So a design may support a different set of IDs compared to the design space it is based on.
Note that the set of supported IDs is not the same as the set of IDs that are valid for a design. It is possible to get and set values for an ID that is not included in the set.
In InPUT4j, this operation is supported by the getSupportedParamIds
method.
This operation allows a design to be exported in some appropriate format.
In InPUT4j, this operation is supported by the export method, which
takes some Strategy depending on the desired format.
Trying to get a value for an invalid parameter ID should be illegal.
Extending a design with an overlapping design should be illegal. It should at least produce a warning.
Supported IDs should include all the IDs that are valid.
Extending a read-only design should be illegal. As for the back-door effect of extending a design, this is an issue that should be examined more closely.