Hi
Le ven. 24 janv. 2020 à 19:32, Paolo Bonzini <
address@hidden> a écrit :
On 22/01/20 13:42, Marc-André Lureau wrote:
> From the top of my mind, this is the pain point when trying to use GObject:
> - static/inlined object, not supported by GObject, unlikely to ever be
> - few users in qemu, transition possible.
> - 64k limit of GObject, for some reason, unlikely to change but I will
> take a look. Some users in qemu, code adaptation possible.
> - dynamic properties, possible in GObject with hacks, but not
> recommended and going to be deprecated from what I remember
> - "array" properties - would need extra layer/tweaks for compatibility
> - link properties - would need special handling
> - different limitations for type names and properties names
The properties in general are very different between QOM and QAPI. They
have different limitations and features as Marc-André mentioned, but an
especially important one is the integration with QAPI visitors. This is
what allows us to support -object and object-add with the same code, and
is what separates QOM from GObject the most.
Maybe it would be possible to build an adapter, but having written in
the past code that uses GType to do marshalling and unmarshalling, I'm
not really fond of repeating the experience...
I agree it is one of the things that look very different from gobject. At the same time, I think defining conventions/types or interface to describe hierarchy isn't so difficult, and then adapting the visitors shouldn't be either.
I try to find a good reason qom was chosen over gobject, and I can't find it.