[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Integrating QOM into QAPI
From: |
Paolo Bonzini |
Subject: |
Re: Integrating QOM into QAPI |
Date: |
Sun, 26 Jan 2020 17:47:09 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 |
On 26/01/20 10:11, Marc-André Lureau wrote:
>> I’m still puzzled as to why anybody would switch to something like
>> GObject when there is C++.
> C++ is another level of complexity.
>
> Replacing QOM with GObject would mainly bring us a more solid type
> system with better tooling/features, gobject-introspection support,
> and remove the burden of having our own OO from QEMU code base.
In fact, C++ doesn't solve any of the problems that either QOM or
GObject try to solve. (Neither does Rust for that matter).
Nevertheless, there is no stupid question, only stupid answers, and I
think Christophe's remark is an example of a common misconception. In
the hope of not making this a stupid answer, let my try to formulate
succinctly what I think the differences are between QOM, GObject and the
C++ object model:
- the C++ object model (at least "old-style" C++ with virtual functions
and the like) provides you with _the intersection_ of what QOM and
GObject try to solve. This is what Marc-André calls "OO", and it's
essentially virtual functions and dynamic casts. It's a relatively
small part of both QOM and GObject, and unfortunately a wheel that
almost every large C program ends up reinventing.
- Marc-André also described above what GObject provides: a fully
introspectable type system and the tools so that _libraries_ can define
_types that will be used from multiple programming languages_.
- QOM also provides a fully introspectable type system, but with a
different focus: it's so that _objects_ can expose _properties that will
be accessed from multiple channels_.
Everything else in both GObject and QOM follows from this core purpose,
and the differences between the two follow from the differences. For
example:
- GObject's focus on multiple programming languages:
gobject-introspection, GClosure, support for non-object types (scalar
and GBoxed)
- QOM's focus on objects: dynamic properties, object tree, all types are
classes
- QOM's focus on properties: no introspection of methods
- QOM's support for multiple channels: visitors
Paolo
- Re: Integrating QOM into QAPI, (continued)
- Re: Integrating QOM into QAPI, Markus Armbruster, 2020/01/23
- Re: Integrating QOM into QAPI, Paolo Bonzini, 2020/01/24
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/24
- Re: Integrating QOM into QAPI, Paolo Bonzini, 2020/01/25
- Re: Integrating QOM into QAPI, Peter Maydell, 2020/01/25
- Re: Integrating QOM into QAPI, Christophe de Dinechin, 2020/01/26
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/26
- Re: Integrating QOM into QAPI,
Paolo Bonzini <=
- Re: Integrating QOM into QAPI, Christophe de Dinechin, 2020/01/27
- Re: Integrating QOM into QAPI, Christophe de Dinechin, 2020/01/27
- Re: Integrating QOM into QAPI, Peter Maydell, 2020/01/26
- Re: Integrating QOM into QAPI, Christophe de Dinechin, 2020/01/27
- Re: Integrating QOM into QAPI, Markus Armbruster, 2020/01/28
- Re: Integrating QOM into QAPI, Daniel P . Berrangé, 2020/01/28
- Re: Integrating QOM into QAPI, Christophe de Dinechin, 2020/01/29
- Re: Making QEMU easier for management tools and applications, Marc-André Lureau, 2020/01/15
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/15
- Re: Making QEMU easier for management tools and applications, Paolo Bonzini, 2020/01/25