Type Converter Enhancements #78
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request implements a series of changes intended to enhance and improve the use of type converters. It partially addresses #68, but does not include line or column numbers. It also fixes #66.
ITypeConverter's conversion methods now take thePropertyInfoof the class property being converted to or from. This provides type converters with much needed context and metadata. For example, custom attributes could be applied to properties and then retrieved during conversion. Unfortunately, this is a major breaking api change. I am open to suggestions about ways to ease or avoid this. An entirely new interface could be added, but I did not pursue that.Feature Request - More detail in ITypeConverter #68 specifies "Destination Object Type (not the property)", but
PropertyInfoprovides access to this information and more.When writing files,
ITypeConverter.ConvertToStringwas not being used at all, relying simply onToString().LineBuilderBasehas been modified to use a type converter if provided.Finally, two additional methods were added to
IFieldSettingsConstructor:WithConversionFromStringandWithConversionToString. These both take lambda functions, one converting to a property's target value from a string when reading, and the other converting from a property's value to a string when writing. These are simpler to use than implementing a fully-fledged type converter, but the existing type conversion machinery is still used underneath.I tried to get the inferred property type to flow from the
WithMembercall, but after several aborted attempts, I gave up. The interaction of inherited interfaces and generic type arguments is fairly complex, and I could not find a way to make it work.