implement Signature and Marshal for params::Variant

[MaxVerevkin]

My usecase: I was implementing org.freedesktop.DBus.Properties.GetAll which returns a{sv}. In Rust's types that would be HashMap<&str, Variant>, but I couldn't use it because of the missing impls. Container::make_dict_ref("s", "v", ...) works, but not nearly as ergonomic and forces to go through push_old_param instead of the new push_param.

I did not implement Unmarshal, because I didn't need it yet. Let me know it I should add it too for completeness.

[KillingSpark]

I'd like to have a test that covers this in src/tests/verify_marshalling.rs. There is a verify_variant_marshalling test at the end where you can add a codeblock for this codepath. Doesn't have to be extensive but having something there that breaks when something becomes obviously wrong in the future is nice.

If it's not too much trouble I'd like a unmarshal implementation too.

[KillingSpark]

Is there a reason not to use the trait based Variant (now that it's actually usable)? No reason not to have this but I wanted to discourage the params based API but I wasn't sure if there are cases they cover the trait based API doesn't

[MaxVerevkin]

Yes, for org.freedesktop.DBus.Properties.GetAll I need a dict with arbitrary values. I cannot use the Variant newtype because Variant<Param> doesn't work since Param does not implement the necessary traits (and it cannot implement them because Signature methods are associated functions and not member functions, but the signature of Param is only known at runtime).

[MaxVerevkin]

I'd like to have a test that covers this in src/tests/verify_marshalling.rs. There is a verify_variant_marshalling test at the end where you can add a codeblock for this codepath. Doesn't have to be extensive but having something there that breaks when something becomes obviously wrong in the future is nice.

If it's not too much trouble I'd like a unmarshal implementation too.

Will do.

[KillingSpark]

for org.freedesktop.DBus.Properties.GetAll I need a dict with arbitrary values

Does a map with Box<dyn Marshal> as values not work?

[MaxVerevkin]

Marshal is not object safe

[MaxVerevkin]

I wanted to discourage the params based API

BTW, I think this change is moving things in this direction. Instead of using get_param() to get a param and then extracting a variant, you can use the new get::<Variant>().

Does this improve #83?

[MaxVerevkin]

Oh, also, even with the new trait-based API, I believe having an enum with all possible dbus types is necessary. At least for receiving variants in args. And sending them...

[KillingSpark]

// signature ++ padding ++ 32u8

Sorry to be this nit-picky but the test uses 16u8, otherwise lgtm 👍

[KillingSpark]

Oh, also, even with the new trait-based API, I believe having an enum with all possible dbus types is necessary. At least for receiving variants in args. And sending them...

There is the Variant struct that allows you to get the correct type (or a param) from the contents. That should work for these cases I think?

[MaxVerevkin]

There is the Variant struct that allows you to get the correct type (or a param) from the contents. That should work for these cases I think?

I actually didn't had a chance to use it yet, will try :)