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
Note the public Subsystem methods will create a temporary pipeline and context if needed. This avoids extra overloads on the subsystems.
Design 1
This design favors limiting passed data to what is available (not providing a null ParseResult to Initialize) and comfortably usable (not providing an exit code to CheckIsActive).
This would expect, perhaps require, that everything in the template used the same ConsoleHack (with a great new name of course).
Configuration, Ars, ParseResult and RawInput would be null or throw if called prior to parsing.
This would tie the current state of the CLI to a particular execution.
Design 3
This design retains the Pipeline as shown in Basic API Shape and creates a new class called Cli. In this mindset, the Pipeline is what is done to the Cli and the Cli is a combination of the Cli shape and the pipeline context information.
I have a hard time getting into this mindset.
Current plan
I am most comfortable in the mindset that there is a CLI configuration/definition and a pipeline it can run against, and the run is ephemeral. Thus I think the first design is the right one. With tweaks as we like.
The text was updated successfully, but these errors were encountered:
Scenarios:
-h
) and calls a subsystem explicitly. This may be for performance and is an advanced scenario.Changes to consider that do not need explanation
Cli
GetIsActivated
may need a new nameBasic API shape
Accessing subsystems directly is an advanced scenario so is via static methods on the Subsystem class.
The method parameters are discussed in the next sections.
Note the public
Subsystem
methods will create a temporary pipeline and context if needed. This avoids extra overloads on the subsystems.Design 1
This design favors limiting passed data to what is available (not providing a null
ParseResult
toInitialize
) and comfortably usable (not providing an exit code toCheckIsActive
).Design 2
Use the pipeline as the source of truth and have the Pipeline be a required parameter to
CliSubsystem
constructor.This would add the following to
Pipeline
shown above (and soon to be renamedCli
).This would expect, perhaps require, that everything in the template used the same
ConsoleHack
(with a great new name of course).Configuration, Ars, ParseResult and RawInput would be null or throw if called prior to parsing.
This would tie the current state of the CLI to a particular execution.
Design 3
This design retains the
Pipeline
as shown in Basic API Shape and creates a new class calledCli
. In this mindset, thePipeline
is what is done to theCli
and theCli
is a combination of theCli
shape and the pipeline context information.I have a hard time getting into this mindset.
Current plan
I am most comfortable in the mindset that there is a CLI configuration/definition and a pipeline it can run against, and the run is ephemeral. Thus I think the first design is the right one. With tweaks as we like.
The text was updated successfully, but these errors were encountered: