On Thu, Sep 29, 2016 at 12:12:32PM +0200, Andreas Färber wrote: > Am 29.09.2016 um 10:14 schrieb Daniel P. Berrange: > > On Thu, Sep 29, 2016 at 10:16:41AM +1000, David Gibson wrote: > >> QOM has the concept of both "object class" properties and "object > >> instance" properties. > >> > >> The accessor functions installed for the rarely-used class properties > >> still take an Object *, so the *value* of such properties is still > >> per-instance; it's just the *existence* (and type) of the property > >> that is per-class. > > > > Yes, of course. This is the whole point of class properties. It avoids > > allocating the same ObjectProperty struct against every object instance > > which wastes massive amounts of memory in scenarios where there are lots > > of instances created. > > +1 > > >> Of course, that's also true in practice for the great majority of > >> "instance" properties, because they're created identically and > >> unconditionally for every instance from the per-class instance_init > >> hook. > >> > >> This also means that the (unused) object_class_property_add_*_ptr() > >> functions don't make a lot of sense, since they require a fixed > >> pointer which means the value of such a property would only be > >> per-class. > >> > >> Given that, is there really any value to supporting the "class" > >> properties in addition to the "instance" properties? This series is > >> an RFC which removes all support for class properties, changing the > >> few existing users to instance properties instead. > >> > >> Alternatively, if we *don't* want to remove class properties, should > >> we instead be trying to convert the many, many "instance" properties > >> whose existence is actually per-class to be class properties? > > > > Practically all instances properties should become class properties > > as its going to save wasting memory once most are converted. > > Not all, but most. child<> properties were the reason to have properties > on the instance.
That's why I said "Practically all", instead of just "all" :-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
