-
Notifications
You must be signed in to change notification settings - Fork 29
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
Remove EventListener::new footgun #91
Comments
I agree with the idea that If the listener is linked into the list on the first poll of the loop {
if check_the_flag() {
break;
}
let mut listener = EventListener::new(&event);
pin!(listener);
// Poll the future once to insert it into the list.
future::poll_once(listener.as_mut()).await;
if check_the_flags() {
break;
}
// Now we can fully await on the listener.
listener.await;
} This introduces a much larger footgun, however, as a naive user may just try to loop {
if check_the_flag() {
break;
}
let listener = EventListener::new(&event);
pin!(listener);
listener.await;
} Inserting on first poll also neglects the One possible way around this is to have the first |
Thanks so much for explaining in detail.
That doesn't seem extremely bad to me but yeah, I agree it's still a bit weird/unexpected behavior. As I wrote on the Matrix channel, I've no objection on doing a 4.0 release that fixes it. If we do that, IMO we should yank the 3.0 on crates.io. |
Sounds good. But we should probably wait until we roll out the rest of |
That would delay zbus 4.0 even further than it already is. :( Why don't we do both:
|
event-listener is not used by any other smol crates public API, so I think it is okay to make a new breaking release (4.0) right now if needed. |
Oh, even better! |
This is a breaking change. It makes `new()` take no parameters in its signature and `listen()` take a reference to an event in its signature. This should avoid a footgun where a listener can be waited on without listening on it. Closes #91 Signed-off-by: John Nunley <[email protected]>
This is a breaking change. It makes `new()` take no parameters in its signature and `listen()` take a reference to an event in its signature. This should avoid a footgun where a listener can be waited on without listening on it. Closes #91 Signed-off-by: John Nunley <[email protected]>
This is a breaking change. It makes `new()` take no parameters in its signature and `listen()` take a reference to an event in its signature. This should avoid a footgun where a listener can be waited on without listening on it. Closes #91 Signed-off-by: John Nunley <[email protected]>
This is a breaking change. It makes `new()` take no parameters in its signature and `listen()` take a reference to an event in its signature. This should avoid a footgun where a listener can be waited on without listening on it. Closes #91 Signed-off-by: John Nunley <[email protected]>
This is a breaking change. It makes `new()` take no parameters in its signature and `listen()` take a reference to an event in its signature. This should avoid a footgun where a listener can be waited on without listening on it. Closes #91 Signed-off-by: John Nunley <[email protected]>
As discussed in #90 and #89,
EventListener::new
has a big footgun: it takes&Event
ref but doesn't add itself to listen to the event passed. This is highly unintuitive IMO and if possible, we should remedy this. Two options here:new
in favor of that. ORlisten()
implicit in the first poll ofEventListener
and deprecateEventListener::listen
.I'd very much prefer the 2, since it removes the footgun completely.
The text was updated successfully, but these errors were encountered: