From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: QOM: should you be able to cast from an interface class to the concrete class?
Date: Tue, 8 Nov 2022 17:52:27 +0000 [thread overview]
Message-ID: <Y2qXWwAvQ1ACva1R@redhat.com> (raw)
In-Reply-To: <CAFEAcA8Q3XZrdLJhJ4Uj1CX6J04ON9f91p=NuJXxA+cnEfdz6Q@mail.gmail.com>
On Tue, Nov 08, 2022 at 04:01:56PM +0000, Peter Maydell wrote:
> Hi; in the QOM model, are you supposed to be able to cast from
> an interface class to the concrete class that is implementing it?
>
> To give a specific example, if I have a ResettableClass *rc
> should I be able to do DeviceClass *dc = DEVICE_CLASS(rc);
> (assuming that the rc I have is actually from a DeviceClass) ?
>
> If I'm reading the code correctly, at the moment this isn't possible:
> object_class_dynamic_cast() has code for "if the class we're
> casting from implements interfaces and the class we're casting to
> is an interface, then look through the list of interfaces to
> see if we should be returning the class pointer from the interface
> list", which means you can cast from the concrete class to the
> interface class. But there's no code there to say "if the class
> we're casting from is an interface, try the concrete class".
>
> As far as I can see we do actually record the information we need
> to do this -- InterfaceClass has a field concrete_class that points
> to the concrete class that's implementing it. But this field is
> currently only written, never read.
>
> Should we:
> (a) support casting from the interface class back to the concrete
> class, by adding some extra code in object_class_dynamic_cast(), or
> (b) decide that that isn't something we should be wanting to do,
> and remove the dead concrete_class struct field ?
My rule of thumb would be, if it is possible with GObject, then
it is reasonable to want it in QOM, and indeed you can cast
from an interface in GObject, back to the concrete type that
has implemented it. So I'd go for (a).
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2022-11-08 17:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 16:01 QOM: should you be able to cast from an interface class to the concrete class? Peter Maydell
2022-11-08 17:52 ` Daniel P. Berrangé [this message]
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=Y2qXWwAvQ1ACva1R@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=eduardo@habkost.net \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--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).