Can you clarify why having log.Logger be an interface would be helpful? Any library can define their own Logger interface with the same methods as the log.Logger type (e.g. Printf, Fatalf), and that would allow that library to take a reference to some generic "logging implementation" without being tied to the standard library. One could argue that there should be a centrally-defined interface which all possible loggers should "definitely" implement, but given that one could define their own interface with a subset of necessary functions it does not seem like a big deal.
To the original poster: can you just declare your own Logger-like interface and allow users of your library to pass whatever logging implementation they have? In what ways are you thinking that you're forced to be coupled with the standard library's implementation? On Sunday, August 29, 2021 at 12:10:54 AM UTC-6 Amnon wrote: > Yes, this is a massive pain. > > The standard library's log.Logger is not an interface, despite ending in > er. > > If it was an interface, it would be easy for third party packages to > implement it, and then it would > be a lowest common denominator for any package where doing some logging > could be useful. > > Unfortunately it is too late to change this. > > On Sunday, 29 August 2021 at 00:38:50 UTC+1 amits...@gmail.com wrote: > >> Hi all, a huge disclaimer - I am not familiar with the design >> decisions and internal details of anything that follows. They are >> coming from the point of view of a consumer of the language and the >> ecosystem and also someone trying to write about these things for an >> audience. >> >> Say I have an application - a HTTP server, where I initialize a >> log.Logger as implemented by the standard library and then I inject >> that into the handler functions where they call the Printf() or the >> other methods to log stuff. Say I have also configured a middleware to >> log data for every request, once again using the Printf() and family >> functions. >> >> Now, I want to implement some levelled and/or structured logging. So, >> here's my expectation - I should just be able to update the initial >> code and everything else should not be changed. Of course, in due >> course of time, I will update those to take advantage of the actual >> functionality offered by those libraries - levelled logging, >> structured logging. But, initially, my code should just build and >> work. Many years back, that's how I really found >> https://github.com/sirupsen/logrus useful and exciting. However, some >> more performant and recent packages don't seem to have that >> compatibility as a goal. For example, https://github.com/uber-go/zap >> doesn't AFAICT implement the Printf() or other functions. However, >> https://github.com/rs/zerolog does, which is great. >> >> I imagine this possibly is due to the standard library not exporting >> publicly available types for - logging handlers, formatters (encoders) >> and such that third party packages have difficulty implementing these >> in standard library compatible way? >> >> To summarize, I would have really wanted a way to avoid my code >> becoming tightly coupled with the logging library I am using but that >> seems to be hard at this stage. >> >> What does the community think? >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1480daa8-b93a-415a-bb4a-e4c6769afb88n%40googlegroups.com.
