Like others have said, go with #2, and to help those developers who are new to Go, provide easy to find (maybe in the README) examples of what to do when they don't actually have any useful context value to pass. That will save them time searching around to see what context is, what to use it for and what to do when you still don't want it/need it.
Regards, Diego On Sunday, April 16, 2017 at 2:06:05 PM UTC-4, Dragos Harabor wrote: > > #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.
