I thought about this a bit in the context (:drum:) of #132.
Want to open this up for a discussion as we're storming towards v1. Does it feel completely out of place to accept context?
Problem
While we did make room for ProvideOption
and InvokeOption
, neither are currently implemented and I don't see them fulfilling all the future use cases.
At the very least to implement each an additional datastructure for each is going to be required. Something like provideConfig
, or provideContext
or provider
which encapsulates rules an options for a particular Provide call, like hooks, or rules for how to skip frames.
context.Context
can actually fill some of those roles.
Implications
User-facing API
User-facing consumption of dig is going to suffer due to an additional parameter. I don't think this is a big deal, as we've spun dig to be a library to build frameworks, rather than for direct consumption.
Fx
Fx API won't be affected, we can keep them as is. That should allow us to smooth over the aforementioned issue.
Potential confusion
If we start forking between Options
and context.Context
it might be confusing what goes where.
???
Are there any more drawbacks?
Benefits
Timeouts & cancellation
Invocation on a type can actually take a long time, depending on the size of the graph. I think it would be wise to leave room for timeouts and context.Context
things.
c := c.New()
// ...
err := c.Invoke(context.WithTimeout(10 * time.Second), func(A,B,C) { ... })
???
Let me know if I'm missing something