[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now)
From: |
Paolo Bonzini |
Subject: |
Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now) |
Date: |
Tue, 29 Sep 2020 20:23:36 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 29/09/20 19:55, Marc-André Lureau wrote:
> My understanding of what you propose is:
> - ForeignConvert::with_foreign
> - FromForeign::from_foreign (with implied into_native)
> And:
> - ForeignConvert::as_foreign (with the BorrowedPointer/stash-like)
> - ToForeign::to_foreign + ForeignConvert::as_foreign_mut (which seems
> wrongly designed in your proposal and unnecessary for now)
Might well be, but how is it wrong? (I'd like to improve).
> I don't have your head, so I find it hard to remember & work with. It> uses
> all possible prefixes: with_, from_, as_, as_mut, to_, and into_.
> That just blows my mind, sorry :)
Ahah I don't have your head either! The idea anyway is to reuse
prefixes that are common in Rust code:
* with_: a constructor that uses something to build a type (think
Vec::with_capacity) and therefore takes ownership
* as_: a cheap conversion to something, it's cheap because it reuses the
lifetime (and therefore takes no ownership). Think Option::as_ref.
* from_/to_: a copying and possibly expensive conversion (that you have
to write the code for). Because it's copying, it doesn't consume the
argument (for from_) or self (for to_).
* into_: a conversion that consumes the receiver
It may well be over the top.
> Then, I don't understand why ForeignConvert should hold both the "const
> *P -> T" and "&T -> const *P" conversions. Except the common types,
> what's the relation between the two?
Maybe I'm wrong, but why would you need just one?
> Finally, I thought you introduced some differences with the stash
> design, but in fact I can see that ForeignConvert::Storage works just
> the way as ToPtr::Storage. So composition should be similar. Only your
> example code is more repetitive as it doesn't indirectly refer to the
> trait Storage the same way as glib-rs does (via <T as ToPtr>::Storage).
Yes, that's the main difference. I removed Storage because I didn't
want to force any trait on BorrowedPointer's second type argument. It
seemed like a generic concept to me.
The other difference is that Stash is a tuple while BorrowedPointer is a
struct and has methods to access it. Stash seems very ugly to use.
> I am not making any conclusions yet, but I am not exactly happily going
> to switch to your proposal yet :)
Sure, no problem.
Paolo
- [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), marcandre . lureau, 2020/09/10
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Paolo Bonzini, 2020/09/11
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Paolo Bonzini, 2020/09/11
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Marc-André Lureau, 2020/09/11
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Paolo Bonzini, 2020/09/11
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Marc-André Lureau, 2020/09/29
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now),
Paolo Bonzini <=
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Marc-André Lureau, 2020/09/30
- Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Paolo Bonzini, 2020/09/30
Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Daniel P . Berrangé, 2020/09/11
Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Marc-André Lureau, 2020/09/11
Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now), Markus Armbruster, 2020/09/21