-
Notifications
You must be signed in to change notification settings - Fork 624
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
Separate interfaces from no-op impls #166
Comments
That's the problem then, we need a no-op implementation for the Meter. I don't see how separating ABCs and no-ops helps. Relatedly, the tracer no-op mode is also in a bad shape: #142. |
This is assuming we don't actually want implementers extending the no-op classes, but there may be an argument for writing them to be extended instead. As it is now, a |
Would the idea here be to define a no-op tracer and to make Meter, Span and Tracer ABCs? |
Yes! With the goal of clearly separating the API and default implementation. |
I think @Oberon00 raised a really good point that Vendors will most likely extend the default implementations, as it provides a layer of safety where newly required methods will not cause the SDK they build to fail. As ABCs only provide value if they're used directly, we might as well make Default / No-op interfaces and make that the pattern. |
BTW, it seems this issue is actually a duplicate of #66. |
Closing this one in favor of #66. |
From #160 (comment), related to #165.
We don't currently distinguish between abstract classes/interfaces and no-op implementations in the API package. We expect implementations to override the no-op
opentelemetry.trace.Tracer
class, which also serves as theTracer
interface. This pattern causes problems forMeter
in #160 because we don't have a no-op implementation.Consider separating these classes, and making it impossible to accidentally load interfaces by making them
ABC
s, as inResource
.The text was updated successfully, but these errors were encountered: