from_message_parts into from_message
#183
Conversation
|
Does it make sense to abstract away the nature of the mismatch? In my mind, it'd be much more useful to have specific descriptions of the mismatch, instead of having library users needing to add a bunch of debugging to figure it out. Just my thoughts. Let me know. |
|
Otherwise, this is a welcome change. I'm glad that a rename and redesign was considered. |
I lean towards that a mismatch is not an error at all. If it matches 'false', nothing 'bad' happened, the outcome is just not what you want. |
|
In the case of |
|
Hmmmm.... It looks like this breaks my goal of keeping common WASM compatible. I'm still thinking about this to see if it's strictly necessary, and if it is, how can we still integrate this. I'm in favour of fewer lines of boilerplate code :) |
Constructing errors breaks WASM? What rule should I not have broken?
What do 'it' and 'this' refer to? Greetings from the disambiguation dept!
|
luukvanderduim
force-pushed
the
new-generic-event-trait-ext
branch
from
7f2b6c4
to
68f9e4d
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #183 +/- ##
==========================================
+ Coverage 86.69% 86.90% +0.20%
==========================================
Files 39 39
Lines 3338 3421 +83
==========================================
+ Hits 2894 2973 +79
- Misses 444 448 +4 ☔ View full report in Codecov by Sentry. |
Builds on 'new-generic-event-trait'
`from_message` takes just one argument, `&zbus::Message` and converts
into the `BusProperties` implementing type.
This avoids crreating a body in the cases we do not need one.
This also introduces a `MessageExt` trait that provides `matches_event`
This allows users who have / prefer a `MessageStream` over the `event_stream`
to do something like this:
```Rust
if msg.matches_event::<AbsEvent>()? {
AbsEvent::from_message()?
} else {
Err(AtspiError::EventMisMatch)
};
```
or simply use:
```Rust
AbsEvent::try_from(msg)?
```
Which now uses `matches_event`.
Lastly, this has a few little optimizations that avoid clones
in a conversion.
`Ok(Self { item: msg.try_into()? })`
We tried to re-export zbus for convenience, if the user wished so but did not h ave the corresponding feature in Cargo.toml. This fixes that.
This thanges `BusProperties::from_message` to `try_from_message` to better hint at what it returns. Also fixes a dependency problem Clippy found in crate atspi, where we tried to re-export zbus (but failed) because we did not have the `zbus` feature present in that crate. This add zbus as optional dependency to that crate.
…nition This introduces more verbose specific & verbose on why the conversion from `Message` failed. Only disadvantage is perhaps that we need to use the error type `Owned`, because we have to construct the error from runtime gathered parts.
We cannot compile zbus in WASM context, so this branch's use of `Message` in the `BusProperties::try_from_message` method is problematic. Because `BusProperties` is used to blanket-implement some other traits, this commit tries to be least intrusive and avoids having `try_from_message` in the trait when zbus is not set as feature. The obvious downside is that `BusProperties` now has two sets of behaviour, depending on the "zbus" feature. That being said, `try_from_message` is not relevant anyway without zbus support.
Fixes `ObjectRef` type path in `atspi-common`
Fix docs
TTWNO
force-pushed
the
new-generic-event-trait-ext
branch
from
08e6f49
to
6833743
Compare
Builds on 'new-generic-event-trait'
from_messagetakes just one argument,&zbus::Messageand converts into theBusPropertiesimplementing type.This avoids crreating a body in the cases we do not need one.
This also introduces a
MessageExttrait that providesmatches_eventThis allows users who have / prefer aMessageStreamover theevent_streamto do something like this:or simply use:
Which now uses
matches_event.Lastly, this has a few little optimizations that avoid clones in a conversion.