LUMIERA.clone/tests/16parameter.tests

TESTING "Library Test Suite: parameters" ./test-suite --group=param


TEST "Parameter Values" Parameter_test <<END
return: 0
END


TEST "Parameter Domain Type" ParameterDomain_test << END
return: 0
END


PLANNED "Parameter Provision" ParameterProvision_test << END
return: 0
END
Parameters: start a design draft Parameters and Automation will certainly play a crucial role eventually. They will form a network of relationships to cover all further concerns that can not directly be conceptualised as arrangement or processing. A shift in the setup of the Job-Functor arguments necessitates to introduce a `Parameter` type — ''albeit just as placeholder'' 2026-07-01 01:50:26 +02:00			`TESTING "Library Test Suite: parameters" ./test-suite --group=param`



Parameter: simple testcase PASS (see #1431) Add value access implementation of the Provision interface by direct cast and access to the embedded value in `ParamData<VAL>`; obviously this is an indirect dispatch, based on the actual type `VAL` The test demonstrates the basic machinery built thus far - have an embedded container with inline storage - dispatch using type information encoded into the VTable 2026-09-02 01:48:51 +02:00			`TEST "Parameter Values" Parameter_test <<END`
Parameters: start a design draft Parameters and Automation will certainly play a crucial role eventually. They will form a network of relationships to cover all further concerns that can not directly be conceptualised as arrangement or processing. A shift in the setup of the Job-Functor arguments necessitates to introduce a `Parameter` type — ''albeit just as placeholder'' 2026-07-01 01:50:26 +02:00			`return: 0`
			`END`
Parameters: preliminary requirement analysis In the current stage, a design-draft is required that is sufficiently adequate to be used as code placeholder and to evolve into the full specification eventually. - we need a single parameter container type with value semantics - parameters must support a selection of basic value types, with conversions - the value range can be limited, and a parameter can be associated with a ''Scale'' (stepped, continuous, logarithmic) - a parameter can be linked to a functional source - parameters are (virtually) copyable 2026-07-03 19:55:55 +02:00

Parameters: look for a suitable arrangement of interfaces While the role of all the relevant interfaces has been determined, it still remains difficult to establish a sensible relationship. Which one is the most fundamental interface? After a lot of mulling, it seems that the `Provision` interface should be used as foundation, since it describes the very core of the parameter concept developed here -- even while the actual form of the operations must be ''somewhat cunningly reversed'', so that the knowledge regarding the underlying type can be kept an opaque implementation detail. The `Domain` interface would then be layered on top, and describes the capability to transfer values between buffers marked with different domains (which effectively requires a double-dispatch in the general case). 2026-08-31 23:17:32 +02:00			`TEST "Parameter Domain Type" ParameterDomain_test << END`
			`return: 0`
			`END`


			`PLANNED "Parameter Provision" ParameterProvision_test << END`
Parameters: preliminary requirement analysis In the current stage, a design-draft is required that is sufficiently adequate to be used as code placeholder and to evolve into the full specification eventually. - we need a single parameter container type with value semantics - parameters must support a selection of basic value types, with conversions - the value range can be limited, and a parameter can be associated with a ''Scale'' (stepped, continuous, logarithmic) - a parameter can be linked to a functional source - parameters are (virtually) copyable 2026-07-03 19:55:55 +02:00			`return: 0`
			`END`