"Daniel P. Berrange" <berra...@redhat.com> writes: > 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.
That's a really good point. To generalize it a bit, introspection of actual interfaces is fine, but permitting introspection of how they are made can add artificial constraints. Introspecting the subtype relation is already problematic in this view.
