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
On Tue, Aug 31, 2021 at 9:46 PM Robert Engels 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
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)
> On
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
On Tue, Aug 31, 2021 at 8:58 AM Kevin Chowski wrote:
> 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
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
Maybe it is worth checking out:
https://github.com/go-logr/logr
On Sunday, August 29, 2021 at 8:10:54 AM UTC+2 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
zap for example provides both:
RedirectStdLog to capture all output and
NewStdLog to produce a preconfigured std log.Logger
On Sunday, August 29, 2021 at 8:10:54 AM UTC+2 Amnon wrote:
> Yes, this is a massive pain.
>
> The standard library's log.Logger is not an interface, despite ending in
>
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
