Intercept provided values

[asmeikal]

This is our current implementation for #408. It adds a container Option to intercept values as they are constructed, to apply additional startup logic.

The naming could certainly be improved!

[codecov]

Codecov Report

Attention: Patch coverage is 90.47619% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 98.29%. Comparing base (897df36) to head (cd7d216).

❗ Current head cd7d216 differs from pull request most recent head 16c63d6. Consider uploading reports for the commit 16c63d6 to get more accurate results

Files	Patch %	Lines
result.go	81.81%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #409      +/-   ##
==========================================
- Coverage   98.40%   98.29%   -0.12%     
==========================================
  Files          22       22              
  Lines        1507     1524      +17     
==========================================
+ Hits         1483     1498      +15     
- Misses         15       17       +2     
  Partials        9        9              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JacobOaks]

Hey @asmeikal - thanks for working with us to get this to this state! One thing I think warrants discussion:

Giving access to the actual reflect.Values returned by constructor/decorators in callback opens up opportunity for some funky stuff. For example, I think callback functions will be able to use reflect to modify the actual values stored inside containers (for addressable values at least), which could definitely cause unexpected/unsound behavior. One alternative I can think of would be to make sure that the values passed to callbacks are deep copies of those stored in the container, but I'm not sure that would be worth it.

So, my initial thoughts are that this is probably fine, as long as we aggressively plaster clear documentation that modifying these values results in undefined behavior, but I'd like to hear your thoughts & thoughts of other maintainers @tchung1118 @sywhang.

[tchung1118]

I agree with @JacobOaks that this is probably fine, but we should clearly document that those values in CallbackInfo shouldn't be modified.

[JacobOaks]

Given the discussion, let's add some explicit documentation here that mentions the undefined results of modifying these values.

[asmeikal]

I updated the comment!

[JacobOaks]

Hey there, the maintainers of Dig discussed this at some length and decided to open up a discussion to describe our concerns and solicit more thoughts: #410