Remove No-Op instrument and Meter creation restrictions #3322
Conversation
The current No-Op requires all instruments to be created from a Meter and a Meter to be created from a MeterProvider. This was inherited from the SDK specification, but it is not necessary. The No-Op performs no operations and hold no state, therefore creating these objects directly will not have logical or processing consequences. This change is desired by the Go SIG. We want to export these No-Op types so users can create them directly. This will allow them to embed these No-Op types in their SDKs to define default behaviour, and allow them to use them directly for testing (instead of having to go through the creation chain all starting with a MeterProvider).
I don't understand the motivation. Code can always do |
|
The types need to be exported to be able to be embedded in SDK implementations. If they are exported they can be created directly. If they can be created directly then the implementation is not spec compliant. |
|
Only NoopProvider needs to be exported in my example, not the individual instruments. |
|
The issue is not with reference to instances of the type, but the type identifier itself. To embed a type it must be referenced where it is to be embedded. To reference a type outside of the package where it is declared it must be exported. type MyCounter struct {
noop.Int64Counter
// other fields
}No instances of the type are involved and being able to create an instance of a |
|
@carlosalberto can we include this in the upcoming release? |
|
markdown-link-check :( |
That failure doesn't look related to these changes. It looks like another PR is needed to address the failure in ./specification/common/attribute-type-mapping.md. |
…ry#3322) The current No-Op requires all instruments to be created from a Meter and a Meter to be created from a MeterProvider. This was inherited from the SDK specification, but it is not necessary. The No-Op performs no operations and hold no state, therefore creating these objects directly should not have logical or processing consequences. If there are consequences of doing this in a language implementation, they are still permitted to keep this restriction. This change is desired by the Go SIG. We want to export these No-Op types so users can create them directly. This will allow them to embed these No-Op types in their SDKs to define default behaviour, and allow them to use them directly for testing (instead of having to go through the creation chain all starting with a MeterProvider). --------- Co-authored-by: Reiley Yang <[email protected]> Co-authored-by: Joshua MacDonald <[email protected]>
The current No-Op requires all instruments to be created from a Meter and a Meter to be created from a MeterProvider. This was inherited from the SDK specification, but it is not necessary. The No-Op performs no operations and hold no state, therefore creating these objects directly should not have logical or processing consequences. If there are consequences of doing this in a language implementation, they are still permitted to keep this restriction.
This change is desired by the Go SIG. We want to export these No-Op types so users can create them directly. This will allow them to embed these No-Op types in their SDKs to define default behaviour, and allow them to use them directly for testing (instead of having to go through the creation chain all starting with a MeterProvider).