On Fri, Oct 23, 2020 at 05:33:14PM +0200, Igor Mammedov wrote: > On Wed, 21 Oct 2020 09:30:41 -0400 > Eduardo Habkost <ehabk...@redhat.com> wrote: [...] > > I don't love object*_property_add_*_ptr() either. I consider the > > qdev property API better. But we need a reasonable alternative, > > because the qdev API can't be used by non-device objects yet. > > I don't think object*_property_add() and > > object*_property_add_bool() are reasonable alternatives. > > I also like old qdev API as it can be introspected (it's just data at > class level), very concise when used and has default values. > > Instead of duplicating all that pointer arithmetic from qdev properties > in QOM API, it could be better to fix qdev properties so that they > would work for Object as well. > At least all that thrown away type safety would stay constrained/hidden > inside of qdev property macros, instead of being opencoded (offsets) all > over the place. > > How hard it would be make qdev properties to work with Object and what > makes you duplicate ugly part of it in QOM instead of making them to > handle Object strait away?
It is doable, but lots of work. I'm working on this right now. > That would also result in huge removal of boiler plate of current QOM > properties. Yep. > > That should suit your goal to make (most) properties introspectable > and statically described. That's correct. I just don't want a huge qdev refactor to be a reason to delay important work in other areas. -- Eduardo
