TL;DR
- Consider the deprecation of all or parts of the
Step interface variants following the introduction of the StepRunner API (ie. the implementation of [old_issue]).
- One possible path would be to deprecate and then remove
IndexableStep and PayloadStep while keeping InputStep as it sees more use and is more likely to be used for lambda steps
Details
They played an essential role in simplifying the API for a set of common use-cases for steps, considering the vast majority of Step implementations do not require half of its signature method's inputs.
Current Step variants are:
InputStep which allows accessing the pipeline's argument, this is the most common use-case by a long milePayloadStep which allows accessing the whole payload (ie. what was produced by the Initializer)IndexableStep which allows accessing the pipeline thread's object (ie. what was indexed by an Indexer after initialization)
The simplification happened by exposing relevant arguments in the variant contract, which helped with the having simpler method signatures for class-based implementations, but was also instrumental to making lambda implementations usable. It is important to keep in mind that [old_issue] cannot, by definition, concern itself with lambda-based implementations. Any measure taken here has to take into account the impact for both class-based and lambda-based implementations (even if the first type is a lot more prevalent).
Looking at the list of variants, the one obvious thing to note is that there are two families:
- one that cares about payloads
- one that does not care about payloads
In fact, this is mirrored with the pipeline builder API, where we have a slightly more compact builder implementation for pipelines that do not want to care about a payload (Pipeline.ofPayload and Pipeline.ofSimple), which is something we might want to address at some point.
One way we could tackle this issue, is by dropping support for less common patterns, and hold on "actually useful" variants. Before [old_issue] we needed variants for "all" expected patterns, now if the annotation-based mode is the preferred route, we could retain only Step as the reference, feature-complete, implementation ; and perhaps InputStep as a shorthand interface for easier lambda-based implementations.
TL;DR
Stepinterface variants following the introduction of theStepRunnerAPI (ie. the implementation of [old_issue]).IndexableStepandPayloadStepwhile keepingInputStepas it sees more use and is more likely to be used for lambda stepsDetails
They played an essential role in simplifying the API for a set of common use-cases for steps, considering the vast majority of
Stepimplementations do not require half of its signature method's inputs.Current
Stepvariants are:InputStepwhich allows accessing the pipeline's argument, this is the most common use-case by a long milePayloadStepwhich allows accessing the whole payload (ie. what was produced by theInitializer)IndexableStepwhich allows accessing the pipeline thread's object (ie. what was indexed by anIndexerafter initialization)The simplification happened by exposing relevant arguments in the variant contract, which helped with the having simpler method signatures for class-based implementations, but was also instrumental to making lambda implementations usable. It is important to keep in mind that [old_issue] cannot, by definition, concern itself with lambda-based implementations. Any measure taken here has to take into account the impact for both class-based and lambda-based implementations (even if the first type is a lot more prevalent).
Looking at the list of variants, the one obvious thing to note is that there are two families:
In fact, this is mirrored with the pipeline builder API, where we have a slightly more compact builder implementation for pipelines that do not want to care about a payload (
Pipeline.ofPayloadandPipeline.ofSimple), which is something we might want to address at some point.One way we could tackle this issue, is by dropping support for less common patterns, and hold on "actually useful" variants. Before [old_issue] we needed variants for "all" expected patterns, now if the annotation-based mode is the preferred route, we could retain only
Stepas the reference, feature-complete, implementation ; and perhapsInputStepas a shorthand interface for easier lambda-based implementations.