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
