-
Notifications
You must be signed in to change notification settings - Fork 57
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
Proposal: be more strict about WithListener #113
Comments
@costela I think it's a fairly large change to break API compatibility for ergonomic reasons. I'm not against this but this is probably not going to be a priority for us for quite a while. Can I tag this as a maybe later issue? If you're willing to expand on this idea a little and do PR I'd be open to reviewing it but it's unlikely we'll merge it until we do a major version release for this SDK, which is probably going to be a while |
hi @sighphyre! Totally understand the reluctance. I'll cook up a PR and check how much would actually break. |
You're amazing, thank you @costela! |
Hey 🙋 It's been a while now. Is there any progress on this? @costela Did you get anywhere with the PR? |
Describe the feature request
I would like to make
WithListener
more strict about its parameter, requiring the consumer to implement some of the listener interfaces.The rationale being: it's less work to implement a NOOP interface than it is to debug code that silently doesn't do what it's told.
Background
Currently, when using
WithListener()
, it is possible to introduce silent errors by not implementing any of the listener interfaces. Thesync()
goroutine will be started, but none of the listeners will be set.This is presumably intentional, so that one can turn the sync on without having to actually implement anything (
WithListener(struct{}{})
), but it is also extremely error-prone.The following snippet showcases how easy it is to miss this:
Note the interface-mismatch: we test against a pointer (
*unleashListener
) but pass a copy (unleashListener{}
).Solution suggestions
We could trivially check if any listener interface is implemented in
NewClient
, but that would be a tricky compatibility breakage: old code would compile, but not run.Maybe it would be better to break the API completely and change
ConfigOption
into the following?With this, we could move a lot of the validation code currently living in
NewClient
to its respective option.WDYT?
The text was updated successfully, but these errors were encountered: