From: Paolo Bonzini <pbonzini@redhat.com>
To: Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: marcandre.lureau@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/3] qom-qobject: introduce object_property_{g, s}et_ptr
Date: Fri, 24 Feb 2017 18:12:59 +0100 [thread overview]
Message-ID: <302e693e-9f6f-52b5-a662-a2d7d35da0a3@redhat.com> (raw)
In-Reply-To: <488abb9e-d1d3-30ad-18e1-3a00bb7f10d8@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]
On 24/02/2017 17:54, Eric Blake wrote:
>> 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?
It's not about adjusting the rest the code, it's about the other code
not caring about the data in the subtype. Why should it be using it
rather than the supertype?
Paolo
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2017-02-24 17:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-22 18:04 [Qemu-devel] [PATCH v2 0/3] simplify struct QOM properties and use the result for GUEST_PANICKED Paolo Bonzini
2017-02-22 18:04 ` [Qemu-devel] [PATCH 1/3] qom-qobject: introduce object_property_{g, s}et_ptr Paolo Bonzini
2017-02-22 23:34 ` Eric Blake
2017-02-23 8:33 ` Marc-André Lureau
2017-02-24 14:54 ` Markus Armbruster
2017-02-24 15:29 ` Paolo Bonzini
2017-02-24 16:54 ` Eric Blake
2017-02-24 17:12 ` Paolo Bonzini [this message]
2017-02-24 19:18 ` Markus Armbruster
2017-02-22 18:04 ` [Qemu-devel] [PATCH 2/3] cpu: implement get_crash_info through QOM properties Paolo Bonzini
2017-02-22 18:04 ` [Qemu-devel] [PATCH 3/3] vl: pass CPUState to qemu_system_guest_panicked Paolo Bonzini
2017-02-22 18:13 ` [Qemu-devel] [PATCH v2 0/3] simplify struct QOM properties and use the result for GUEST_PANICKED no-reply
2017-02-23 8:34 ` Marc-André Lureau
-- strict thread matches above, loose matches on Subject: below --
2017-02-21 10:42 [Qemu-devel] [PATCH " Paolo Bonzini
2017-02-21 10:42 ` [Qemu-devel] [PATCH 1/3] qom-qobject: introduce object_property_{g, s}et_ptr Paolo Bonzini
2017-02-21 11:56 ` Paolo Bonzini
2017-02-21 16:36 ` Marc-André Lureau
2017-02-21 15:57 ` Eric Blake
2017-02-21 16:23 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=302e693e-9f6f-52b5-a662-a2d7d35da0a3@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).