-
Notifications
You must be signed in to change notification settings - Fork 203
Add support for binder to create models #467
Comments
You can think of I had proposed moving it out of the package and into general config for this reason and to make it less confusing, but we didn't want to add the component model dependencies. My personal opinion is that there would be value in a universal |
I don't have a huge preference as to whether there's "one method to rule them all" vs. separate methods for each thing, but I figured |
|
Yeah I think the confusion mostly lies around GetValue living in the binder. If it lived somewhere else, I don't think it would be as confusing. Or if it was called ConvertValue. |
I think |
Note if we end up resurrecting a bind overload, we might as well bring it back as |
Ship has unfortunately sailed for 1.0.0 for the name... |
@HaoK @tillig I guess we can all have different subjective perspectives of that is confusing and why. Trying to be objective, as @HaoK mentioned we are going to ship this as is in 1.0.0 and so I believe it may be more productive to think about:
Back to my own subjective perspective:
|
My vote is to bring back the uber The proposed behavior for
If there's ambiguity somehow there, users can manually call Bind instead. But I'm still convinced Get will just work 95% of the time... |
I liked I get that name changes are out, and I'm totally fine with that. A clearer name for
I'm primarily concerned about filling the gap (additive to the API? minor enhancement to existing API?) with some way to call The largest confusion I had was that neither method had such functionality but by all accounts felt like it should have. |
Yeah well that gap is where The good news is if enough other people agree and also request it, we can probably bring it back in some form (it helps your cause that I never wanted to remove it)... |
/missing the Get. That being said, writing a custom extension yourself which uses Maybe it would be more clear if we would have So, that Bind and |
@MichaCo yes, that is what I had in mind when I said we can create more convenient versions of |
I went with Do we need an overload that takes a string which is a shortcut for the common: |
Currently if you want to bind configuration to any sort of user-defined model, you have to create the model and then bind:
You have to do that because
GetValue<T>
only uses type conversion to convert the value in a specific key into a destination type. So something like this works......but something like this doesn't work:
This becomes really painful if you want to bind an array of settings back into an array. If I want an enumerated list of settings, it has to be like:
Other similar scenarios become multi-step pain, too. Instead of only using type conversion in the
GetValue<T>
mechanism, it would be nice if that process would also make use of the (private)CreateInstance
method in the binder already and create a new version of the model/bind that new version if possible.The text was updated successfully, but these errors were encountered: