Use latest dbus-codegen #120
Conversation
| pub fn supported_includes(&self) -> Option<&Vec<String>> { | ||
| arg::prop_cast(self.0, "SupportedIncludes") | ||
| } | ||
| } |
There was a problem hiding this comment.
I feel like this PR validates our earlier decision to make a bluez-generated crate that only contains generated code.
There was a problem hiding this comment.
Generating it as part of a build.rs would also work, but this is simpler in some ways.
| .unwrap() | ||
| .to_string() | ||
| }); | ||
| let device_properties = OrgBluezDevice1Properties::from_interfaces(&interfaces)?; |
There was a problem hiding this comment.
(mostly rambling and probably re-hashing the discussion from your upstream PR, so feel free to ignore me)
I feel like it's a bit surprising that device_properties owns a reference into interfaces, but I guess it is efficient and device_properties will typically be short-lived, so it's probably fine (I also can't think of a better way to do it).
I suppose if you were only asking for a single property then you'd be using a fluent interface (OrgBluezDevice1Properties::from_interfaces(&interfaces)?.address()?) and it would not be surprising at all.
I suppose if OrgBluezDevice1Properties was a trait with a blanket impl over &'a ::std::collections::HashMap<String, arg::PropMap> then it could be written OrgBluezDevice1Properties::address(&interfaces), but people would be tempted to use OrgBluezDevice1Properties and write interfaces.address()? which might be a bit fragile.
There was a problem hiding this comment.
Yeah, it looks a little weird, but seems to work well in practice so far. The other issue with the trait approach is that I want from_interfaces to return something that can be passed around, which is a bit of a pain if it's a trait object.
Note that from_intefaces is doing one level of HashMap lookup, and address() is doing a second level.
mijia/src/bluetooth/mod.rs
Outdated
| .iter() | ||
| .filter_map(|(k, v)| match Uuid::parse_str(k) { | ||
| Ok(uuid) => { | ||
| let v = cast::<Vec<u8>>(&v.0)?; |
There was a problem hiding this comment.
(optional) should we be noisier if this cast fails?
There was a problem hiding this comment.
Added a warning log.
34aec5e to
83a95f9
Compare
This includes my addition diwic/dbus-rs#304 to add type-safe property parsing, which makes things a bit neater.
Fixes #9.