Open blumamir opened 2 months ago
Pros options 1:
Pros options 2:
_config
private to decrease API surface.tracer
, meter
and logger
class properties, which are private and are only accessed via a getter.Here is my opinion. If we already have a public API to access the field I think we should leverage that for accessing even in subclasses. Also I'm not sure about the significance the perf gain of having direct access to the config which is the most appealing pro of option 1.
Here is my opinion. If we already have a public API to access the field I think we should leverage that for accessing even in subclasses. Also I'm not sure about the significance the perf gain of having direct access to the config which is the most appealing pro of option 1.
I agree. IMO we should go with getConfig()
and make _config
private.
Implemented in https://github.com/open-telemetry/opentelemetry-js-contrib/pull/2289 Would appreciate any review on this PR 🙏
Now that https://github.com/open-telemetry/opentelemetry-js/pull/4659 will soon merge, all instrumentations can apply cleanups to how the config object is consumed.
There are now 2 options:
this._config
fromInstrumentationAbstract
which is now typed correctly.getConfig()
function from the Instrumentation interface.I think we should decide which one is superior and refactor all existing instrumentations to use a consistent pattern. I tend to prefer the
getConfig
option as the getter can potentially be overridden with custom logic which will be lost if we simply access the_config
property.If we choose option (2), should we make the
_config
objectprivate
instead ofprotected
?Would love to hear more opinions.