Hi Le ven. 24 janv. 2020 à 19:32, Paolo Bonzini <pbonz...@redhat.com> 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. >
