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
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
The text was updated successfully, but these errors were encountered:
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 ofSet
andTryGet
.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
andValueFuncAnnotationAccessor
in #2413.Some examples:
Parameter type checking:
DefaultValue
needs to be held in a collection ofobject?
, but if we have the specific symbol, we can ensureSet
requires a parameter of that type andTryGet
supplies the correct value typeDefaultValueCalculation
is similar to the above, except thatFunc<TSymbolType>
is used inSet
andTryGet
Multiple overloads
CliOption
andCliArgument
. This can be done with overloadsCliSymbol
(non-generic). Thus, annotations likeDefaultValue
need a non-generic versionAdditional methods
Get
method to simplify callsite usageCustom behavior
The text was updated successfully, but these errors were encountered: