Historically we've insisted that the Context be passed explicitly so that
it's always visible in the code and accessible to refactoring tools. In
reality, tools that assist in context plumbing don't exist yet, and there
are examples of putting Context inside some other structs in the standard
The Context as "a bag of stuff" is attractive since it makes your code
easier to refactor (knock, knock) but gives me void* or as Jakob said
map[string]interface{} vibes.
I think I think it should be avoided but probably not unconditionally. I
guess there can be cases where it makes sense.
ons
@Dave, isn't storing context in some struct considered anti-pattern? From the
package doc:
"
Programs that use Contexts should follow these rules to keep interfaces
consistent across packages and enable static analysis tools to check context
propagation:
Do not store Contexts inside a struct
I'd say store that context in your transaction value, not the other way around.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I'd like input on whether the following idea is good or bad, and why.
Consider an abstract transaction, modeled as follows:
func Transaction(ctx context.Context, body func(ctx context.Context) error)
error
func OnCommit(ctx context.Context, commitHook func(ctx context.Context))
func
