Deprecate or remove `ScopeManager.active()`

ScopeManager.active is documented as a feature used to get the current span. Perhaps it is a relic from the previous design. It tempts people to call close on it eventhough ScopeManager is pretty clear that scopes should be managed directly.

I would remove this api, possibly for ScopeManager.activeSpan if that’s the intended use case to serve. Otherwise, please clarify the documentation that calls to close are undefined.

If folks are doing things like subclassing, you can deprecate the api, and they can still offer “advanced” things as they exist today as their subtype would still be able to offer that functionality regardless of it it exists on a supertype.

https://github.com/openzipkin-contrib/brave-opentracing/pull/74#issuecomment-380382654

[carlosalberto]

Hey @adriancole

I’m not sure why there is a concept of removing active scope in favor of span… why this is somehow experimental. This was in use in brave and also census for quite a long time. Retrieving the scope is the thing that causes issues

So, if I understood correctly, you would like ScopeManager.active() to go in favor of ScopeManager.activeSpan() and keep the notion of Scope (through startActive()) otherwise? That sounds fine (by me, at least 😉 )

So the testbed notion is precisely for testing how API changes could impact different use cases. The change for active() -> activeSpan() is not that complex, so it wouldn’t require as many iterations in that regard (and I can do a PR myself for that); but if we decide to try to change the Scope notion, well, that would require more effort on that front, for good or bad 😉

Nevertheless, I can definitely help with that as needed.

[CodingFabian]

Well there is this spec proposal to give access to span id for example, so implementations need to provide a way to access the instance anyway. We currently have no problem with this API.