On Mon, Nov 07, 2016 at 03:48:49PM +0100, Halil Pasic wrote: > > > On 11/07/2016 02:05 PM, Eduardo Habkost wrote: > > If you want some subclasses to not have the property, then I > > recommend not registering it as a class property on the base > > class in the first place. I don't expect to see a mechanism to > > allow subclasses to remove or override class properties from > > parent classes. > > > > Thank you very much for your reply. > > I understand, yet I see potential problems. The example with ioeventfd > and vhost in virtio-pci is a good one also because the first there was > the ioeventfd property with commit 653ced07 and then the vhost case came > along with commit 50787628ee3 (ok ioeventfd is not there for some non > vhost virtio-pci devices for reasons I do not understand). > > To rephrase this in generic context a specialization for which a > property does not make sense might come along after the property at the > base class was established. > > Now AFAIU properties are external API, so having to make a compatibility > breaking change there might not be fun. Does this mean one should be > very careful to put only use class level properties on abstract classes > where its certain that the property always makes sense including it's > access control?
This could be an argument for *NOT* allowing introspectiing of properties against abstract parent classes. If you only ever allow introspecting against leaf node non-abstract classes, then QEMU retains the freedom to move props from a base class down to an leaf class without risk of breaking mgmt apps. 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/ :|
