opentelemetry-go: Inconsistency with pointer and concrete type recievers
core.Number has a mix of pointer and concrete receivers. E.g.
func (n *Number) AddFloat64(f float64)
func (n Number) IsNegative(kind NumberKind) bool
We don’t do this in Go for the user’s convenience even if we don’t mutate any fields in the methods.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 17 (17 by maintainers)
Commits related to this issue
- Consistently use pointer receivers for core.Number (#375) Change all occurrences of value to pointer receivers Add meta sys files to .gitignore Code cleanup e.g. - Don't capitalize error statement... — committed to open-telemetry/opentelemetry-go by elsesiy 5 years ago
- Allow custom labels to be added to net/http metrics (#306) * Allow custom labels to be added to net/http metrics * CHANGELOG entry * Add license to labeler.go * Address PR Feedback: * Add... — committed to hstan/opentelemetry-go by Aneurysm9 4 years ago
Thank you @rakyll.
For the types in question, I think we should probably use pointer receivers.
IMHO, it means that be consistent such that if a pointer receiver is needed, always use a pointer for convenience, otherwise default to value receiver.
To clarify, we shouldn’t change all types across the code base, just those which are commonly used as as values and are used in chained expressions.
NumberandValueshould be fixed, for sure.