tree 5b10d51aec35cb7fa15bde01339c4a4d11bce45e
parent 98cc5a0785f9389a91393b250df90a27725107fc
author Jonathan Amsterdam <jba@google.com> 1675110340 -0500
committer Jonathan Amsterdam <jba@google.com> 1675703790 +0000

slog: call Value.Resolve so Handlers don't have to

Resolving a slog.Value means calling its LogValue method,
if there is one, and using the resulting Value instead.

Up until now, it has been the Handler's responsibility to call
Resolve. This CL moves that responsibility to the slog package.

Besides easing the burden on Handler writers, this change also
guarantees deterministic behavior. If different Handlers resolved a
Value at different points during processing, and the LogValuer's
result was time-dependent, then the results could differ. This mainly
concerns the attributes passed to Logger.With. They should be resolved
during that call, since they will probably be used in multiple log
events and it would be wasteful to re-invoke LogValue for each event.
Logger.With now resolves the attributes before passing them to
Handler.WithAttrs, removing the possibility of a Handler getting this
wrong.

Record.AddAttrs now also resolves its aguments before adding them to
the Record.

The Value.Resolve method still has its uses, so we leave it exported.
One use, demonstrated by the built-in handlers, is to resolve
attributes returned by a user-supplied function like
HandlerOptions.ReplaceAttr.

To anticpate a question: why don't we resolve even earlier, when a
Value is first created? One purpose of this mechanism is to delay
computation until it is sure to be useful. So we don't want to resolve
a Value before Handler.Enabled has returned true.

Change-Id: I61c4380f381b40c338ca0b3eea44e12a2c6a2192
Reviewed-on: https://go-review.googlesource.com/c/exp/+/464100
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>