Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider exporting a non-generic TelemetryClient #15

Closed
ranweiler opened this issue Feb 12, 2020 · 0 comments · Fixed by #211
Closed

Consider exporting a non-generic TelemetryClient #15

ranweiler opened this issue Feb 12, 2020 · 0 comments · Fixed by #211

Comments

@ranweiler
Copy link
Contributor

TelemetryClient is actually generic in an (unconstrained) type C. All of the practically interesting impl's of TelemetryClient bound C: TelemetryChannel. Furthermore, the only ctors for TelemetryClient assume that C = InMemoryChannel, specifically.

For ergonomic reasons, consider hiding this abstraction from users, exposing the abstracted version separately.

One easy mechanism could be via exporting a type alias for TelemetryClient<InMemoryChannel>. But, thanks to the recent export of InMemoryChannel, users can do this themselves. My guess is that in practice, users will always want to use the default client that uses InMemoryChannel, and it would be fine to just assume this for the top-level export, letting exceptional users opt in to a more parameterized ("Ex") version.

Another way you could remove the generic parameter: enclose the channel in a Box<dyn TelemetryChannel>, at the cost of some indirection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant