I don’t agree with Rob’s assessment. Standardized interfaces is what has allowed the Java 3P library ecosystem to be so robust.
It takes more design work upfront and you can get things wrong - but it’s a price and risk worth taking in my opinion. > On Aug 31, 2021, at 4:02 PM, Amit Saha <amitsaha...@gmail.com> wrote: > > On Tue, Aug 31, 2021 at 9:46 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> The io.Writer is too low level to be useful. Imagine a logger that wants to >> send an sms on severe errors only. >> >> The best solution is to declare your own logger interface - but similar to >> the collections discussion it would better if the stdlib declared an ILogger >> interface (or similar) > > I found this FAQ entry on zap's project: > > """ > Why aren't Logger and SugaredLogger interfaces? > > Unlike the familiar io.Writer and http.Handler, Logger and > SugaredLogger interfaces would include many methods. As Rob Pike > points out, "The bigger the interface, the weaker the abstraction." > Interfaces are also rigid — any change requires releasing a new major > version, since it breaks all third-party implementations. > > Making the Logger and SugaredLogger concrete types doesn't sacrifice > much abstraction, and it lets us add methods without introducing > breaking changes. > > Your applications should define and depend upon an interface that > includes just the methods you use. > """ > > The last sentence is interesting here which is pointing application > authors to, I think define their own interface for logging which can > then be implemented by a concrete type such as standard library's > logger or zap's or zerolog's. > > > >> On Aug 31, 2021, at 3:48 AM, Rupert Paddington <blm...@gmail.com> wrote: >> >> If Logger was an interface it would be pretty large and to some extent >> application-specific, which is undesirable. >> >> Instead inject the sink (io.Writer). >> >> This is preferable in every way: >> >> * the interface is small and universal >> * it eliminates the coupling with any specific library present and future >> * it requires to test the behaviour instead of the collaboration >> >> These are the same principles why for example the http.Handler interface >> takes an http.ResponseWriter, and then the outcome of the response can be >> tested by reading from the writer that is passed at testing time. >>> On Tuesday, 31 August 2021 at 03:19:29 UTC+1 amits...@gmail.com wrote: >>> >>>> On Tue, Aug 31, 2021 at 8:58 AM Kevin Chowski <ke...@chowski.com> wrote: >>> >>> <snip> >>> >>> >>>> 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? >>> >>> Yes, I can do that - that's a good idea actually - although more >>> complicated than one I would have liked for my use-case (more on this >>> in my original post and below), but certainly a feasible one with long >>> term benefits. >>> >>>> In what ways are you thinking that you're forced to be coupled with the >>>> standard library's implementation? >>> >>> When I first add some logging to my application, I am doing it using >>> the standard library's log.Printf(), log.Println(), log.Fatal() and >>> friends. Now, I reach a point of time where I want to start structured >>> logging but i want to do it incrementally. My existing Printf(), >>> Println() calls should continue to build. The only change I want to do >>> initially is simply change how I am constructing the log.Logger >>> object. >> >> -- >> 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/c76931fb-4d7e-40f2-84d3-8923dd280748n%40googlegroups.com. >> >> -- >> 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/874D83D2-6CF1-405A-B500-1399DB77785A%40ix.netcom.com. > > -- > 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/CANODV3kQ0uy%3Doi2FvJXtvSeY-k9zVU0AX5BB6HpJJCV8D3D5qQ%40mail.gmail.com. -- 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/C0D0F848-FA63-4331-9A81-44A9F573B826%40ix.netcom.com.
