client_golang
client_golang copied to clipboard
prometheus
Does it make sense for metric constructors to return pointers to structs instead of interfaces?
The Counter and Histogram constructors return interfaces instead of pointers to structs. Now the constructor for Counter returns a Counter interface whose underlying type implements both Counter and ExemplarAdder and the constructor for Histogram returns a Histogram interface whose underlying type implements both Histogram and ExemplarObserver. The users of these clients now need to do type casting just to get the type they want, which I would argue is not ideal. Generally, I believe it makes sense for constructors to return pointers to types instead of interfaces since interfaces are satisfied implicitly and this approach gives the caller more options out of the box.
Would there be any consideration for having these constructors return pointers to exported structs? Alternatively, we could create a new set of constructors that do this so the API can remain stable for existing users.
Fruit for thought.
Thanks for starting this discussion. In fact there is minor inconsistency between NewCounterVec() and NewCounter() (first is returning pointer to struct). Overall, let's try to summarize the problems that you pointed out. To me it sounds like there is only one problem:
- Caller has to cast to
ExemplarObserver|Adderwhen they want to observe or add exemplar.
This is quite indeed annoying if you want to instrument application code with exemplars. Any other trouble I might be missing?
If that is the only issue, then I would probably favour another package enriched by exemplars by default 🤔 (we return structs indeed and each returned struct has both metric and exemplar adder/observer capabilities). We cannot change to a struct or even modify interface much within v1.
NOTE: We are kind of discussing some idea of the client instrumentation extension (another module) that will combine 3 signals metric, logging, tracing in one client which will allow mixed things e.g trigger trace and metric inc and log line in one call. Let us know if that sounds interesting, we can hook anyone into early discussion 🤗
This all has historical reasons (some of them plainly bad design decisions in the past). We had to introduce the weird interface upgrade for ExemplarAdder to prevent breakage when introducing exemplar support. A new major release will clean up those inconsistencies.
