Anaconda, a library for using the twitter api, was released yesterday and the
author asked for comments on #go-nuts. I had one, and another I thought of
a few hours later.

Specifically, much of the anaconda api takes url.Values arguments. I checked,
and sure enough, url.Values is an implementation, not an interface. While this
is fine for the net/url library which never takes this implementation as an
argument, only returning it once or twice, it forces implementation choice
on anaconda's callers.

In theory, it's easily fixed. Anaconda could define an interface that describes
which of url.Values' functions it actually calls and start taking arguments of
that interface type instead of url.Values. No existing callers would have to
make changes.

When I looked into it, however, anaconda passes those arguments to the oauth
library it uses. So I looked into the oauth library. Turns out it also takes
url.Values, not an interface. The oauth library not only uses len and range on
those arguments, it passes them to net/http. So I looked into net/http. To no
one's great surprise at this point, I think, it takes url.Values.

The whole chain could have been avoided if net/url had returned an opaque
type implementing an interface. But why should it? Its use of the type is
fine. The real error is in net/http.

I suppose it's not too late to change net/http. After all, no existing callers
would have to change. A brief check suggests the changes would be trivial since
net/http uses only url.Values.Encode().

But wait. Is the choice in net/http really a mistake? url.Values is a known
good implementation. Should libraries force callers to use it? If the caller
provided a buggy implementation, wouldn't they blame the library? And since
the result of url.Values' work goes into an http request, which the caller
usually can't see, might not problems caused by a bad implementation be...
mysterious?