-
Notifications
You must be signed in to change notification settings - Fork 1
Glossary
StarFruit morphs your model into a System.CommandLine tree in two steps. First it interprets your model into an interim format. This keeps the concern of how to understand your model separate from concerns about how to create System.CommandLine classes. The set of Descriptors define Commands, Options, Arguments and SubCommands.
The descriptor is a common format to contain the user's intent, regardless of what source was interpreted to understand that intent.
The code that does the work to understand your model based on a set of rules. Has a general base class that understands how to build descriptors, and a technology specific derived class that understands how to do things like retrieve an attribute. Examples of possible technology specific derived classes would be Reflection, Roslyn, and JSON.
The code that does the work to create a System.CommandLine parser from your model. We anticipate at least one more technology specific variation to support source generation for design time CLI definitions.
The model describes your CLI and is the container for the results. This is the data source and can be in any format that there is a SpecificSourceMaker to interpret. C# code interpreted via either Reflection or Roslyn.
The group of instructions you need to interpret your model. These are organized in RuleSets for specific tasks.
The rules for accomplishing a specific task classifying symbols, defining command details, defining argument details, defining option details and defining option argument details. Command arguments and options arguments might later be combined.
For each thing the RuleSet needs, such as the Name or Description, there is a strongly typed group of rules. Each of these require a set of operations defined in one of the IRulexxx interfaces, such as IRuleGetValue<string>.
The code that defines data retrieval from a model. For example, a rule could be to retrieve a value from an attribute or munge a name by removing a suffix. Rules receive a set of traits for each item being evaluated. Traits are technology independent, although they are supplied by technology dependent code.
Rules are implementation technology agnostic by design. But some rules are very dependent on implementation. For example, the DerivedFromRule would find derived types via Reflection, or Roslyn, or nested JSON entries, which are very different implementations. But it is not helpful for the CLI designer to be aware of who is implementing the rule, or to break rule portability across technology. Thus, abstract rules define the data that will be provided, but rely on a specific implementation. The derived rule class is switched in automatically during DescriptorMaker startup.
Source item wrapped in an instance that also includes a collection of extracted traits and a Name property.
Traits are characteristics that can be used in rules. They follow generalized ideas - attributes for AttributeRules can be Reflection attributes, Roslyn syntax attributes, or JSON entries. The trait group incudes an IdentityWrapper for the name of the raw item.