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? If yes, how does this relate to patch 5 "Register static properties as class properties" where the object level properties are converted to class level properties? > You have many alternatives in this case: you could use instance > properties What are inheritance properties? Sorry I'm not quite that deep yet to know myself. > , or register it as class property only on some > subclasses (class_base_init could you help you do it on a single > place, instead of duplicating the property registration code on > subclasses). Thanks again, and sorry if I'm a bother. Cheers, Halil
signature.asc
Description: OpenPGP digital signature
