⚡zb,zm: Proxy await properties #1414
Conversation
The `wait_*_for` methods are convenient wrappers around the `wait_property_for` method.
2966cdc to
ee69df1
Compare
| /// | ||
| /// Note that zbus doesn't queue the updates. If the listener is slower than the receiver, it | ||
| /// will only receive the last update. | ||
| pub async fn wait_property_for<T>( |
There was a problem hiding this comment.
I'm now wondering, isn't this achieving the same as you could with futures API easily? 🤔
There was a problem hiding this comment.
It's a convenience function of
use futures::{FutureExt as _, StreamExt as _};
let name;
let predicate;
let fut = {
let event_stream = (proxy.receive_property_changed(name).await)
.then(|ev| async move { ev.get().await });
let mut stream = std::pin::pin!(
futures::stream::once(proxy.get_property::<T>(name).await)
.chain(event_stream) // impl Stream<Item = zbus::Result<T>>
.filter(predicate)
);
// the future roughly equivalent to `proxy.wait_property_for(name, predicate)`
stream.next().map(|item| item.unwrap()) // impl Future<Output = zbus::Result<T>>
};There was a problem hiding this comment.
It's a convenience function of
Right but do you really need to create a future here? 🤔
use futures::{FutureExt as _, StreamExt as _, TryStreamExt as _};
let name;
let predicate;
let event_stream = (proxy.receive_property_changed(name).await)
.then(|ev| ev.get())
.try_filter(predicate);
let next_prop_value = event_stream.try_next().await?;Something like that should work, no? Our binary size is already big (#304) so I'm just wondering if this is a frequently used enough API to justify its existence in zbus, if futures already provide an API to easily do what you need.
There was a problem hiding this comment.
Well, the shortcoming of the property changed stream is that it doesn't return the current value to check if the current value already meets the requirement. Otherwise, the receive_property_changed method is enough.
There was a problem hiding this comment.
Well, the shortcoming of the property changed stream is that it doesn't return the current value to check if the current value already meets the requirement.
Huh? That's what the try_filter in my example do.
There was a problem hiding this comment.
Just to be clear, I'm not saying that PropertyChangedStream already does the whole thing you need. My point was that combined with futures (which is already our dep) API, what you need can likely be achieved with a few LOC.
There was a problem hiding this comment.
Just to be clear, I'm not saying that PropertyChangedStream already does the whole thing you need. My point was that combined with futures (which is already our dep) API, what you need can likely be achieved with a few LOC.
Sure, adding a filter or checking values in loops is the solution we are currently using. But based on the reliance on compile-time checking (property names), we made separate methods for different properties due to they are difficult to generalize.
If there are some settings on the PropertyStream type, it can also solve the problem.
let mut stream = proxy.receive_foo_changed().await.with_current();There was a problem hiding this comment.
Sure, adding a filter or checking values in loops is the solution we are currently using.
That's not the solution I suggested but that works too. The main point is that as long as it's easy and needs a few LOCs, probably not a good idea to add more API to zbus unless we've reasons to believe that it's going to be useful for a big percentage of our users.
. But based on the reliance on compile-time checking (property names), we made separate methods for different properties due to they are difficult to generalize.
You can create a generic API that deals with PropertyStream so you can use it with the result so any receive_*_changed method?
Fix #1412.
Add
wait_property_formethod forProxy/blocking::Proxyand generatewait_*_formethods in theproxymacro.