On 12/12/2016 06:47 PM, Eduardo Habkost wrote: >>>> + */ >>> I think this should not just be a 'temporary hack'... rather document >>> this behaviour for abstract classes? >>> >> Connie, I have to disagree with you on this. I'm fine with this as a >> temporary hack provided it remedies the acute problem, but I would this >> becoming state of art. >> >> The reason for this how abstract class is usually understood in OOP: >> it's like a normal class except you can not instantiate it. Adding an >> extra property rule, and especially such a convoluted one, could result >> in a conflict between intuition and reality. And it's not like we have >> no plan how to do this cleanly. >> >> Why do I say convoluted: >> * Inheriting form abstract and from non-abstract behaves differently. >> * Theoretically we have something like non-abstract (C_3) inherits for >> abstract (AC_2) inherits from non-abstract (C_1) inherits from abstract >> (AC_0), and we set the property P both via AC_0 and AC_2 for an instance >> of C1 we would/could end up having the same problem as we have now (via >> AC_0 taking precedence over AC_2) -- at least I think so. > Well, we could change the code to: > 1) Not check object_class_is_abstract(), and simply register the > globals for all subtypes; > 2) Call qdev_prop_set_globals_for_type() only for > object_class_get_name(), instead of doing it for all > parent classes in qdev_prop_set_globals(). > > But this sounds like a more complicated way of implementing > exactly the same behavior implemented by Greg Kurz in "qdev: fix > the order compat and global properties are applied". >
Yeah. This is what I meant with "And it's not like we have no plan how to do this cleanly.", was trying to convince Connie that this called a hack for a reason. I think we are on the same page. I think this is a really good way to solve the acute problem with a small LOC number. Halil
