You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 23, 2023. It is now read-only.
I noticed that the log.Field object borrows from the convention set up by the zap logging library (https://github.com/uber-go/zap) to reduce allocations on logging by having typed functions (e.g. log.String(...) or log.Bool(...)). The SetTag(...) function does not follow that convention though.
Proposal
I would propose that SetTag takes a similar opentracing.Tag object that also reduces allocations.
For example:
span.SetTag(tag.String("hello", "world"))
Questions to address (if any)
There might need to be some path for rollout and backward compatibility.
The text was updated successfully, but these errors were encountered:
I agree that it doesn't quite make sense to make a user nonbackward-compatible change here.
Maybe adding a new API SetTagTyped. That's a terrible name, but that way it doesn't have impact on consumers. It would just require tracers to upgrade to expose the new API. I feel like changes for tracers are less disruptive than changes for consumers.
Problem
I noticed that the
log.Field
object borrows from the convention set up by the zap logging library (https://github.com/uber-go/zap) to reduce allocations on logging by having typed functions (e.g.log.String(...)
orlog.Bool(...)
). TheSetTag(...)
function does not follow that convention though.Proposal
I would propose that
SetTag
takes a similaropentracing.Tag
object that also reduces allocations.For example:
Questions to address (if any)
There might need to be some path for rollout and backward compatibility.
The text was updated successfully, but these errors were encountered: