#2. It's easy enough to pass context.TODO() to quickly get a client going. On Friday, April 14, 2017 at 5:49:55 PM UTC-7, Jonathan Hall wrote: > > 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.
