Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a value hook func #183

Merged
merged 1 commit into from Nov 26, 2020
Merged

Add a value hook func #183

merged 1 commit into from Nov 26, 2020

Conversation

@camdencheek
Copy link
Contributor

@camdencheek camdencheek commented Mar 28, 2020

Overview

This commit adds a third hook func type which has access to the reflect.Value representations of both the from and the to objects. This gives all the same power of the existing hook functions (types, kinds, and data can all be retrieved from values), but with the additional benefit of being able to modify the to object.

Change scope

This change is largely backwards compatible. The only change of the public API (other than adding a new hook type) is a change in the signature of DecodeHookExec. If that's a sticking point, I think there may be a way around it, but I haven't looked closely at it.

Motivation

Exposing the value of to opens up some really powerful patterns such as:

  • Recursively decoding structs to maps (#166, #124). This PR includes a hook func that does this
  • Setting the concrete struct type behind a destination interface before continuing to decode
  • Setting defaults with tags (#111) or with a Defaulter interface
  • Implement a hook for respecting Unmarshaler interfaces (#115)

Overall, I think if this is done right, it could really open a lot of possibility for more powerful hook funcs. The API works well, but I plan to play around with it a bit more to make sure it's as flexible as possible. I'm obviously open to any feedback

This commit adds a third hook func type which has access to the
reflect.Value representations of both the `from` and the `to`
objects. This gives all the same power of the existing hook functions
(types, kinds, and data can all be retrieved from values), but
with the additional benefit of being able to modify the `to` object.

This change is largely backwards compatible. The only change of the
public API (other than adding a new hook type) is a change in the
signature of `DecodeHookExec`.
@smyrman
Copy link

@smyrman smyrman commented May 15, 2020

Alternate suggestion in #192

@mitchellh
Copy link
Owner

@mitchellh mitchellh commented Nov 26, 2020

I like this! I like that it fits into the existing style of decoder hooks.

As much as I'd rather not break BC, the DecodeHookExec function I've never seen used and probably shouldn't have been publicly exposed in the first place. I think I only did that for testing helper purposes. I'd be okay with breaking API in this PR for that specific API.

I'll merge this as-is, but let me know if you wanted to make other changes to it. Thank you for the tests.

@mitchellh mitchellh merged commit fcb781b into mitchellh:master Nov 26, 2020
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants