I think of this as complementary to duck typing conversions (#21) but it could also be thought of as an alternative.
Any attribute or event argument can be bound to any kind of value in any direction as long as there is a conversion in that direction. So if a mod defines its own data types, and especially if it defines its own views (#26), then it is probably at some point going to want to provide its own conversions.
And fortunately the system is already designed for that, through IValueConverterFactory. It's just a matter of adding it to the addon API (#25), e.g.
public interface IUIAddon
{
IValueConverterFactory? ValueConverterFactory => null;
}
And, similar to custom views, the existing ValueConverter could be given the addons and use them accordingly. Priority-wise, they should probably be looked at near the end, but not quite at the end, e.g. maybe just before StringConverterFactory or CastingValueConverterFactory.
The default VCF just iterates through a list, and it's best of the addon behavior isn't locked in immediately - while there's nothing really wrong with that, it's just not what the API implies it's going to do. So, probably divide into two lists, "pre-addons" and "post-addons" or "fallback".
Writing an IValueConverter and/or factory isn't really a lot of ceremony so I think it's just a matter of documenting it, nothing needs to change in the framework.
Came across a good example of this when writing other documentation: item quality stars. Define an ItemQuality enum and convert automatically to Sprite.
I think of this as complementary to duck typing conversions (#21) but it could also be thought of as an alternative.
Any attribute or event argument can be bound to any kind of value in any direction as long as there is a conversion in that direction. So if a mod defines its own data types, and especially if it defines its own views (#26), then it is probably at some point going to want to provide its own conversions.
And fortunately the system is already designed for that, through
IValueConverterFactory
. It's just a matter of adding it to the addon API (#25), e.g.And, similar to custom views, the existing
ValueConverter
could be given the addons and use them accordingly. Priority-wise, they should probably be looked at near the end, but not quite at the end, e.g. maybe just beforeStringConverterFactory
orCastingValueConverterFactory
.The default VCF just iterates through a list, and it's best of the addon behavior isn't locked in immediately - while there's nothing really wrong with that, it's just not what the API implies it's going to do. So, probably divide into two lists, "pre-addons" and "post-addons" or "fallback".
Writing an
IValueConverter
and/or factory isn't really a lot of ceremony so I think it's just a matter of documenting it, nothing needs to change in the framework.