Hey,
Don't think there is any mentionable overhead in doing that.
___
// WithAttrs returns a new [TextHandler] whose attributes consists
// of h's attributes followed by attrs.
func (h *TextHandler) WithAttrs(attrs []Attr) Handler {
return &TextHandler{commonHandler: h.commonHandler.withAttrs(attrs)}
}
____
It creates a new handler object (shallow copies) but so do also many other
methods.
Am Mo., 25. Aug. 2025 um 20:39 Uhr schrieb JUAN DIEGO LATORRE RAMIREZ <
diegolatorre...@gmail.com>:
> Hey guys, I'm configuring the logger in my app, so I have this interface:
> // package types
> type Logger interface {
> Debug(msg string, args ...any)
> Info(msg string, args ...any)
> Warn(msg string, args ...any)
> Error(msg string, args ...any)
>
> // With returns a Logger that includes the given attributes
> // in each output operation. Arguments are converted to
> // attributes as if by [Logger.Log].
> With(args ...any) Logger
>
> // Operational returns a Logger that includes the given operational
> log information
> // with the key "operationalLogInfo" and sets the key "operationalLog"
> to true
> // in each output operation.
> Operational(operationalLogInfo string) Logger
> }
>
> And I am using the slog package for the implementation. In the case of
> Operational, I defined it because very often I have to log with these 2
> keys, "operationalLog" and "operationalLogInfo", therefore I want to expose
> an API for these types of logs. This is the implementation:
>
> type SlogLogger struct {
> logger *slog.Logger
> }
> // ...
> func (l *SlogLogger) Info(msg string, args ...any) {
> l.logger.Info(msg, args...)
> }
> // ...
> func (l *SlogLogger) Operational(operationalLogInfo string) types.Logger {
> return l.With("operationalLog", true, "operationalLogInfo",
> operationalLogInfo)
> }
>
> and I use that like this: h.logger.Operational("some
> message").Info("handling transfer info...")
>
> My question is if the Operational method is efficient? I mean, I have to
> do a lot of operational logs, and each time I call l.With... is it a
> significant overhead?
>
> --
> 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 visit
> https://groups.google.com/d/msgid/golang-nuts/7e10c173-3a2c-4d1f-a0ce-cd6de3d4f2dfn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/7e10c173-3a2c-4d1f-a0ce-cd6de3d4f2dfn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 visit
https://groups.google.com/d/msgid/golang-nuts/CAC4E5Zm6N02ROEPt9wmu6JfZ-wy0DpDukD8NH0m6ncwjWsiu7A%40mail.gmail.com.
