Annotation accessors were initially envisioned as a single widely used struct. But since it serves as the pipeline between the data provider and the CLI author, it would be desirable to expand its use. Since it is, and should probably remain, a struct this means we are using the annotation pattern in other scenarios. These variations are in the signature and overloads of Set and TryGet.
While this would add complexity to the subsystems, it would allow annotation accessor usage to be tailored for CLI author convenience.
The proposal is to embrace annotation accessors as a pattern, rather than a single class. Examples are the ValueAnnotationAccessor and ValueFuncAnnotationAccessor in #2413.
Some examples:
Parameter type checking:
DefaultValue needs to be held in a collection of object?, but if we have the specific symbol, we can ensure Set requires a parameter of that type and TryGet supplies the correct value type
DefaultValueCalculation is similar to the above, except that Func<TSymbolType> is used in Set and TryGet
Multiple overloads
All of the annotations on value should occur only on CliOption and CliArgument. This can be done with overloads
If the type of the symbol is held in a collection, it is held as CliSymbol (non-generic). Thus, annotations like DefaultValue need a non-generic version
Additional methods
It is possible that some annotations will benefit from a Get method to simplify callsite usage
Custom behavior
If we consider annotation accessors a pattern, instead of a single class, we open the possibility of convenience overloads for the CLI author, such as having multiple parameters that are used to create the item to store
We could validate arguments prior to storage or modify such as providing a ceiling or floor
Annotation accessors were initially envisioned as a single widely used struct. But since it serves as the pipeline between the data provider and the CLI author, it would be desirable to expand its use. Since it is, and should probably remain, a
structthis means we are using the annotation pattern in other scenarios. These variations are in the signature and overloads ofSetandTryGet.While this would add complexity to the subsystems, it would allow annotation accessor usage to be tailored for CLI author convenience.
The proposal is to embrace annotation accessors as a pattern, rather than a single class. Examples are the
ValueAnnotationAccessorandValueFuncAnnotationAccessorin #2413.Some examples:
Parameter type checking:
DefaultValueneeds to be held in a collection ofobject?, but if we have the specific symbol, we can ensureSetrequires a parameter of that type andTryGetsupplies the correct value typeDefaultValueCalculationis similar to the above, except thatFunc<TSymbolType>is used inSetandTryGetMultiple overloads
CliOptionandCliArgument. This can be done with overloadsCliSymbol(non-generic). Thus, annotations likeDefaultValueneed a non-generic versionAdditional methods
Getmethod to simplify callsite usageCustom behavior