search

aloneguid / config

⚙ Config.Net - the easiest configuration framework for .NET developers. No BS.
MIT License
641 stars 85 forks source link

Replace type parsers with TypeConverters #66

Closed maelgrove closed 1 year ago

maelgrove commented 5 years ago

The current implementation uses the ITypeParser contract and various implementations to parse from and convert to configuration values. While this contract is neat and definitely communicates it's intention, it's more or less a duplication of the TypeConverter built-in in the .NET framework. The result of that is basically re-implementing a lot of conversions when for a good part the built-in type converters already would suffice. Question is, wouldn't it make sense to replace it? I've did some changes to the code base in that manner and only 17 out of 162 unit tests fail, mainly the ones converting arrays and collection, which need some special treatment anyway.

This would also be in line with the ConfigurationBinder extensions from aspnet/Configuration.

aloneguid commented 5 years ago

This shouldnt be a problem, definitely. You can get rid of conversion code if it's already part of the framework core.

vector-man commented 5 years ago

This would be great! Looking forward to using this library on my current project.

Edit : would this allow for automatic POCO handling?

maelgrove commented 5 years ago

@vector-man What do you mean by automatic POCO handling?

vector-man commented 5 years ago

@maelgrove I mean saving objects without writing converters.

aloneguid commented 5 years ago

Hey guys, this is coming very soon, there is a prototype I've build already. It's taking time as there are a few issues.

Originally config.net was designed to handle key-value stores easily editable by humans. Of course this is not an issue with rich formats such as XML or JSON because POCOs can be represented easily there. What's more complicated is how do you put a POCO into something that is not designed to hold tree structures, for instance an INI file, Azure Key Vault, Android configuration store, a SQL table etc.. One options would be to serialise POCO into something like JSON and write out as a string, if destination store doesn't support hierarchies.

maelgrove commented 5 years ago

@vector-man The intention behind using type converters as this issue suggests is not having the ability to serialize entire object structures, but to use an existing, framework built-in approach to converting types instead of a dedicated solution.

@aloneguid I'm not sure how exactly this should be done, and if it's really a practicable requirement. Suddenly having json-strings ending up in .ini files would really be awkward, and would also make it a lot harder for people who try to configure a system manually (as we discussed about in the boolean-issue #73). Having a key/value-based configuration is the more common way and I think it suits the purpose. When someone wants to serialize entire object structures, they're probably doing way more than just providing some configuration and should rather use a database. Plus, should serialization really be a concern of a configuration framework?