What would you like?
Currently all methods in DurableContext is overloaded to cover the mostly used combinations of these parameters, but we couldn't cover all use cases as the number of methods would increase exponentially.
A solution to avoid overload explosion is to use parameter builder pattern, e.g.
ctx.step(StepParameters.builder()
.name("a step name") // optional
.resultType(String.class) // or .resultType(new TypeToken<HashMap<String, Integer>>(){}), (or maybe optional if the deserializer doesn't rely on the resultType?)
.function(() -> "result") // or .function(stepCtx -> "result")
.config(StepConfig.builder().build()) // optional
.build());
All the combinations of these parameters (excluding optional resultType as a choice) would need 16 distinct overloaded methods (plus another 16 for async variants). Now we have covered only 8 of them in code..
Possible Implementation
No response
Is this a breaking change?
No
Does this require an RFC?
No
Additional Context
No response
What would you like?
Currently all methods in DurableContext is overloaded to cover the mostly used combinations of these parameters, but we couldn't cover all use cases as the number of methods would increase exponentially.
A solution to avoid overload explosion is to use parameter builder pattern, e.g.
All the combinations of these parameters (excluding optional resultType as a choice) would need 16 distinct overloaded methods (plus another 16 for async variants). Now we have covered only 8 of them in code..
Possible Implementation
No response
Is this a breaking change?
No
Does this require an RFC?
No
Additional Context
No response