ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/16parameter.tests

23 lines
356 B
Text
Raw Normal View History

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
Parameters: mapping out the next steps to draft ...I do ''not intend to go into a parameter deep-dive'' yet, but I want to set out the basic capabilities to be expected...
2026-09-05 18:08:51 +02:00
PLANNED "Parameter value scales" ParameterScale_test << END
return: 0
END
Reference in a new issue Copy permalink