Although it's kind of icky to store instance data on a static field, it is implemented in a robust manner that should prevent any surprises, and the details are hidden from authors of CLIs and authors of subsystems.
A subsystem reference is no longer needed when annotating the CliSymbol objects in the grammar, which makes construction of a pipleline much simpler.
The fluent grammar construction API now looks like this:
new Option<bool>("--greeting").WithDescription("The greeting")
Eventually we will be able to use extension properties:
new Option<bool>("--greeting") {
Description = "The greeting"
}
Note that we still support the IAnnotationProvider model that allows advanced CLI authors to lazily or dynamically provide annotations.
I'm still trying to figure out ways to enforce type safety when using DefaultValue/DefaultValueCalculation with the underlying annotation storage methods SetAnnotation/TryGetAnnotation. However, the SetDefaultValue and SetDefaultValueCalculation specialized setters will at least ensure safety for CLI authors.
Although it's kind of icky to store instance data on a static field, it is implemented in a robust manner that should prevent any surprises, and the details are hidden from authors of CLIs and authors of subsystems.
A subsystem reference is no longer needed when annotating the CliSymbol objects in the grammar, which makes construction of a pipleline much simpler.
The fluent grammar construction API now looks like this:
Eventually we will be able to use extension properties:
Note that we still support the
IAnnotationProvidermodel that allows advanced CLI authors to lazily or dynamically provide annotations.I'm still trying to figure out ways to enforce type safety when using
DefaultValue/DefaultValueCalculationwith the underlying annotation storage methodsSetAnnotation/TryGetAnnotation. However, theSetDefaultValueandSetDefaultValueCalculationspecialized setters will at least ensure safety for CLI authors.