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
When using a second type, conversion between LogSink and Handler has to be done through additional interfaces. That may be the right solution anyway, because it gives implementors who want to support both more flexibility.
package zapr // TODO: put this into logr
import (
"github.com/go-logr/logr"
"golang.org/x/exp/slog"
)
type SlogImplementor interface {
GetSlogHandler() slog.Handler
}
type LogrImplementor interface {
GetLogrLogSink() logr.LogSink
}
// logr.ToSlog
func ToSlog(logger logr.Logger) *slog.Logger {
if slogImplementor, ok := logger.GetSink().(SlogImplementor); ok {
handler := slogImplementor.GetSlogHandler()
return slog.New(handler)
}
// TODO: implement Handler which can write to an arbitrary LogSink.
//
// Problem: LogSinks do their own stack unwinding and need to
// know how many levels to skip to get across the slog.Logger
// frontend into the user code. Probably doesn't have a good
// solution.
return nil
}
// logr.FromSlog
func FromSlog(logger *slog.Logger) logr.Logger {
if logrImplementor, ok := logger.Handler().(LogrImplementor); ok {
logSink := logrImplementor.GetLogrLogSink()
return logr.New(logSink)
}
// TODO: implement LogSink which can write to an arbitrary Handler.
//
// TBD: the stored WithName prefix has to be added to the Record.Message
// or added as a new Attr (but with which key?).
return logr.Discard()
}
https://pkg.go.dev/golang.org/x/exp/slog#Handler and https://pkg.go.dev/github.com/go-logr/logr#LogSink are conceptually similar. If it was possible to implement both interfaces in the same type, then it would be simple to put either slog or logr as user-facing API on top of it.
This is currently not possible because of conflicting parameters for
Enabled
:Would it be possible to rename
Handler.Enabled
? Possible alternatives (just thinking out aloud):EnabledWithContext
SlogEnabled
LevelEnabled
Would it be useful? I think so - but probably not crucial.
My current workaround for https://github.com/go-logr/zapr/blob/master/zapr.go is a second type:
cc @jba @rsc
The text was updated successfully, but these errors were encountered: