-
Notifications
You must be signed in to change notification settings - Fork 853
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dismantle AbstractInstrumentBuilder inheritance hierarchy #5820
Dismantle AbstractInstrumentBuilder inheritance hierarchy #5820
Conversation
Codecov ReportAttention:
... and 6 files with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/SdkDoubleGauge.java
Show resolved
Hide resolved
return this; | ||
} | ||
|
||
@Override | ||
public String toString() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing tests for all of these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting that we should have tests for toString()
methods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do for some (most?) of the toString()
methods; perhaps we should add them for the instrument builders as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, I've traditionally been hesitant to test toString()
because it's supposed to be purely informative and relying on toString()
for real programmatic concerns is probably a bad, fragile practice.
In this case, I might also shy away from testing it because the implementation relies on the toString()
of several other classes, including autovalue generated toString()
from the InstrumentDescriptor
. Is that really that helpful?
.../main/java/io/opentelemetry/sdk/metrics/internal/descriptor/MutableInstrumentDescriptor.java
Outdated
Show resolved
Hide resolved
sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/InstrumentBuilder.java
Outdated
Show resolved
Hide resolved
3f29529
to
a1563a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not getting to this sooner. It's been low priority for me since its just a refactor. But if you're willing to pick it back up I will respond promptly and work to get this approved / merged 🙂.
Replaces #5772.
The use of inheritance for code reuse via
AbstractInstrumentBuilder
was a bitter pill to swallow. I think this cleans up considerably with some delegation and improved encapsulation.I don't believe that this changes any public facing APIs.
I think that all of the
Sdk{MetricType}Builder
classes are just pure delegation now.