Open matthiasbeyer opened 5 months ago
Hi @matthiasbeyer, I like the idea of a more typed interface, not sure if the zbus generator that is being used can that do that or not.
Right now in some of the examples, I have separate struct (for example: NM80211ApFlags) that I'm calling the from_bits function on and it would be cleaner to have that as part of the interface:
ap_security_flags_to_security(
NM80211ApFlags::from_bits(flags).unwrap(),
NM80211ApSecurityFlags::from_bits(wpa_flags).unwrap(),
NM80211ApSecurityFlags::from_bits(rsn_flags).unwrap()
)
I'm open to discussions on the best way forward.
Hi,
what do you think about a more typed interface? For example, the
Device::state
function returns aResult<u32>
, but what if it instead would return aResult<DeviceState>
, which wraps thatu32
with an enum that represents the state of device as something more meaningful?I am not sure how to do that properly within the
zbus
ecosystem though, maybe you have an idea? There's propably a lot of interfaces that could use such strong typing to be more ergonomic to downstream users... I would love to help with that implementation, if you'd lead the way!Anyways, if you want to keep this crate "low level" and only a small layer above
zbus
and not add such abstraction, that's also totally reasonable! I just wanted to ask whether that'd be a way forward here! :wink: