commit | 368a25b2f0c9ccbda5f31d04e6df9f23e294b8b0 | [log] [tgz] |
---|---|---|
author | Jonathan Amsterdam <jba@google.com> | Wed Jun 09 07:17:19 2021 -0400 |
committer | Jonathan Amsterdam <jba@google.com> | Thu Jun 10 11:50:08 2021 +0000 |
tree | 94de84485e6f4fda09dd2934f52c30273429cd7a | |
parent | 8a7358d1686588689ef59e61e3382115c0cc301f [diff] |
event: metric-specific builders This CL imagines that each kind of metric is its own type, and has its own builder. Notes: - Metric values are checked by the language. For example, we can enforce that counter values are unsigned integers. That means, however, that we either have to provide metric types for each common value type, or we have to wait for generics to allow a variety of types. - Builder methods can be tailored to metrics. For example, metric builders have no way to override the metric's namespace. But it's not clear that's the right choice, and I think that's the only method that we might want to omit. - In theory, users can define their own metric types. In practice, they'd have to duplicate a lot of our unexported machinery, or we'd have to export it somehow. - You can't add common labels to a single Builder and re-use that builder for both metrics and other events. Change-Id: Ie99cb3b953e1670fb8d6910f9412885e5dcbc219 Reviewed-on: https://go-review.googlesource.com/c/exp/+/326289 Trust: Jonathan Amsterdam <jba@google.com> Run-TryBot: Jonathan Amsterdam <jba@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Cottrell <iancottrell@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.