-
Notifications
You must be signed in to change notification settings - Fork 497
Description
The new ScopeConfiguration
class added in #3137 is great, but it currently disallows direct initialization of the object:
opentelemetry-cpp/sdk/include/opentelemetry/sdk/instrumentationscope/scope_configurator.h
Lines 136 to 138 in fdee87f
// Prevent direct initialization of ScopeConfigurator objects. | |
explicit ScopeConfigurator(std::function<T(const InstrumentationScope &)> configurator) | |
: configurator_(configurator) |
This makes the class a bit awkward to use. For example, here’s how you’d configure it via the builder when working with environment variables:
auto config = ScopeConfigurator<TracerConfig>::Builder(TracerConfig::Enabled())
.AddCondition(
/* if TRACES_ENABLE is not set, disable traces */
[](const InstrumentationScope&) {
return !std::getenv("TRACES_ENABLE");
},
TracerConfig::Disabled())
.AddCondition(
/* if TRACES_<scope name>_DISABLED is set, disable traces for that scope */
[](const InstrumentationScope& aScope) {
return !std::getenv(
("TRACES_" + aScope.GetName() + "_DISABLED").c_str());
},
TracerConfig::Disabled())
.Build();
With direct initialization, the same logic could be expressed far more concisely:
auto config = ScopeConfigurator<TracerConfig>(
[](const InstrumentationScope& aScope) {
// disable if global flag is unset, or per-scope disabled flag is set
if (!std::getenv("TRACES_ENABLE") ||
std::getenv(("TRACES_" + aScope.GetName() + "_DISABLED").c_str()))
{
return TracerConfig::Disabled();
}
return TracerConfig::Enabled();
});
The direct‑init version is much more readable, especially when you only have a single configurator function.
Proposal:
Allow ScopeConfigurator
to be constructed directly from a single callback (in addition to the existing Builder API).
If this restriction is intentional, could someone explain why direct construction should remain private?