You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current approach of defining constraints against a datasource is fairly 'imperative'. It has been suggested that a more natural approach would lean towards a more 'declarative' approach.
In light of limiting complexity around data tests as much as possible, one could look at a specification as more of a 'configuration' - merely expressing expectations in a simple fashion and not relying on mutations, control flow and loops.
It could be possible to provide an additional API to express constraints: at creation time of a Requirement object. A user could then voluntarily opt in to look at Requirement objects in an immutable fashion. This could but wouldn't need to happen in a wrapper around Requirement.
For now, we are not sure about how to evaluate the upside of such an alternative, more high-level API. Hence, we decided to stay alert and let the idea sink in without a concrete next step.
The current approach of defining constraints against a datasource is fairly 'imperative'. It has been suggested that a more natural approach would lean towards a more 'declarative' approach.
In light of limiting complexity around data tests as much as possible, one could look at a specification as more of a 'configuration' - merely expressing expectations in a simple fashion and not relying on mutations, control flow and loops.
It could be possible to provide an additional API to express constraints: at creation time of a
Requirement
object. A user could then voluntarily opt in to look at Requirement objects in an immutable fashion. This could but wouldn't need to happen in a wrapper aroundRequirement
.For now, we are not sure about how to evaluate the upside of such an alternative, more high-level API. Hence, we decided to stay alert and let the idea sink in without a concrete next step.
cc @jonashaag @kklein
The text was updated successfully, but these errors were encountered: