Exposing tracer property on spans

[SergeyKanzhelev]

From open-telemetry/opentelemetry-js#5

Span has a private tracer property, NoRecordSpan doesn't. I'd prefer to make tracer always available on Span like in OpenTracing. Coming from OpenTracing, I found it challenging not having tracer available on spans, especially that first I assumed it is and started to use it, then my code broke one NoRecordSpan(s).

@hekike, @rochdev

[tylerbenson]

I also think it would be nice since configs are usually exposed via the tracer. Besides, I assume Span will need to have a reference to it anyway to report when finished.

[SergeyKanzhelev]

@tylerbenson in the original issue - the scenario was given to start a child span, not to distinguish configurations. How will you use tracer obtained from Span besides starting child spans?

[rochdev]

We use this with OpenTracing to access the scope manager and to start related spans. The ability to access the tracer configuration would also be a nice addition since right now with OpenTracing the only compliant way to do that would be to assign the configuration to every span context to expose it.

In general, I find that exposing the tracer would result in a cleaner API that replicating some of the available tracer methods on the span class.

[carlosalberto]

I remember that we wanted to do this in OT Java (although we did this for OT Python, for example), and I'm definitely in agreement with this change.

Wondering if there's a way to poke people for a counter example (if there's any at all ;) )

[SergeyKanzhelev]

This becoming even more important and valuable with the named tracers

[tedsuo]

@SergeyKanzhelev I agree. Given the design of span.end, it's extremely unlikely that a span implementation would not to have a tracer reference, so I doubt there is a downside to this.