Re: [Qemu-devel] [PATCH 1/3] qom-qobject: introduce object_property_{g, s}et_ptr

[Eric Blake]

On 02/24/2017 09:29 AM, Paolo Bonzini wrote:

> 
>> Here's a non-ducky way to convert between QAPI types.  QAPI guarantees
>> that a pointer to a QAPI type is also valid as pointer to its base type.
>> One can do:
>>
>>     UserDefOne *one;
>>     UserDefOneMore *more;
>>
>>     *(UserDefOne *)more = *one; // get UserDefOne into UserDefOneMore
>>                                 // members not in one are untouched
>>     *one = *(UserDefOne *)more; // set UserDefOne from UserDefOneMore
>>                                 // members not in one are ignored

And rather than having to write the casts yourself, the generator
produces qapi_UserDefOneMore_base() which returns the proper UserDefOne
pointer (giving you a bit more type safety, and isolates you from any
generator change in layout).

>>
>> Would this technique suffice for your problem?
> 
> I am not sure.  What I'm trying to do here is to keep backwards
> compatibility in case a device provides UserDefOneMore for a well-known
> property name, and another device provides UserDefOneAnother.  As long
> as all devices provide the same (duck-typed) base class, things work.
> 
> Maybe the right thing to do would be to define a union, but I wasn't
> sure it was possible to do that in a fully backwards compatible way (can
> you define a union where the discriminator is optional, for example?).

Not yet, although I've discussed the idea of an optional discriminator
several times before.  As soon as we have a killer use case where an
optional discriminator makes sense, it shouldn't be too hard to add that
support into the generator.

> 
> If you're setting UserDefOne from UserDefOneMore, some of the values are
> going to be lost.  Presumably there was a reason why you used
> UserDefOneMore, and therefore an error is the safe bet.
> 
> If you're getting UserDefOne from UserDefOneMore, some of the values are
> going to be lost.  However, it's reasonable that you didn't even know
> that UserDefOneMore existed, which makes it sensible to allow reading
> into a covariant type.

How often to we add qapi subtypes, but not adjust the rest of the code
base to cope with it existing?  Is it going to be less of a maintenance
burden just patching all the uses of the property getters to deal with
the new type than it is to keep the non-strict visitor?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature