| commit | 033684cbd6a81a49762eafedd408706d0d0c982f | [log] [tgz] |
|---|---|---|
| author | Jonathan Amsterdam <jba@google.com> | Mon Jan 30 15:25:40 2023 -0500 |
| committer | Jonathan Amsterdam <jba@google.com> | Mon Feb 06 17:16:30 2023 +0000 |
| tree | 5b10d51aec35cb7fa15bde01339c4a4d11bce45e | |
| parent | 98cc5a0785f9389a91393b250df90a27725107fc [diff] |
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>
This subrepository holds experimental and deprecated (in the old directory) packages.
The idea for this subrepository originated as the pkg/exp directory of the main repository, but its presence there made it unavailable to users of the binary downloads of the Go installation. The subrepository has therefore been created to make it possible to go get these packages.
Warning: Packages here are experimental and unreliable. Some may one day be promoted to the main repository or other subrepository, or they may be modified arbitrarily or even disappear altogether.
In short, code in this subrepository is not subject to the Go 1 compatibility promise. (No subrepo is, but the promise is even more likely to be violated by go.exp than the others.)
Caveat emptor.