I'm working on a client client API, and am accepting a `context.Context`
argument as the first argument to each function.
However, for ease of use, I'm also providing non-context aware versions of
each method. So my API looks roughly like:
FooContext(ctx context.Context, args...)
Foo(args...)
where Foo(args...) just calls FooContext(context.Background(), args...).
Multiply this times about 25 methods across a few different types, and I
have a very cluttered package (and godoc).
I borrowed this approach from the `sql` package. But the sql package has
about half as many methods, so it seems less cluttered. It also has to
retain backward compatibility with context-unaware code.
Is there anything like a "best practice" in this area, given that (unlike
the `sql` package) I have no backward compatibility to maintain?
Some options I've considered:
1. Keep things as they are.
2. Only expose the 'Context' versions of my methods (and drop the 'Context'
suffix)
3. For each type, add a single `Background()` method, which returns a clone
type, that uses a background context. So `client.Foo()` becomes
`client.Background().Foo()`. This doesn't reduce clutter, but it helps to
organize it on the godoc page, by grouping all the Context-aware methods
together, and the unaware together.
I think I'm leaning toward #2. I imagine a fair number of Go newbies will
find the context argument to be "strange", but I hope documentation will
fix that.
Are there other alternatives I should consider?
Much thanks,
Jonathan
--
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
