[Top][All Lists]

[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

- 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

- QOM's focus on properties: no introspection of methods

- QOM's support for multiple channels: visitors


reply via email to

[Prev in Thread] Current Thread [Next in Thread]