You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to pull request #1 abstracting away all methods into an interface, the implemented methods no longer are formatted as such in the resulting godoc HTML, instead the documentation is shown as Go comment unprocessed which is less intuitive and generally not as nice to read.
Possible solutions:
Remove the intermediate interface and instead make Client struct be able to deal with raw initialization through go's new(...) (in order to reduce redundancy we would deprecate NewClient respectively and support an alternative to setting the HTTP client like SetHttpClient).
Keep as is (without nice formatting/processing of documentation).
The text was updated successfully, but these errors were encountered:
Looks like a bug in Godoc and it will be adressed "one day": golang/gddo#313
Also, as the endpoint is unique, we could do the same than HTTP API: providing methods at package level which would use a default client (which in turn would use the default HttpClient).
(See https://golang.org/src/net/http/server.go?s=57817:57861#L1951)
Sad to see this being a long-standing issue that isn't tackled at the moment - the most relevant issue for this would be golang/go#5860 which has been open for almost 3 years.
Providing methods at package level is a good idea independent from the issue, also considering how packages like "log" solve it as well.
Now that I have time for the project again I would go ahead and implement the methods at package level. I guess the easiest way would be to set up a DefaultClient variable and just wrap all provided methods.
Due to pull request #1 abstracting away all methods into an interface, the implemented methods no longer are formatted as such in the resulting godoc HTML, instead the documentation is shown as Go comment unprocessed which is less intuitive and generally not as nice to read.
Possible solutions:
new(...)
(in order to reduce redundancy we would deprecateNewClient
respectively and support an alternative to setting the HTTP client likeSetHttpClient
).The text was updated successfully, but these errors were encountered: