On 30/07/20 14:36, Markus Armbruster wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > >> On 30/07/20 12:03, Markus Armbruster wrote: >>> qdev C layer: >>> >>> frob->prop = 42; >>> >>> Least cognitive load. >>> >>> QOM has no C layer. >> >> Not really, a QOM object is totally free to do frob->prop = 42. And >> just like we didn't do that outside device implementation in qdev as our >> tithe to the Church of Information Hiding; the same applies to QOM. > > I screwed up the part of my argument that actually has a hope to be > valid, let me try again. > > With qdev, you can always do frob->prop = 42, because properties are > always backed by a struct member. > > With QOM, properties are built around visitor-based getters and setters. > This means you can always do (but never actually would do) something > like > > fortytwo = qnum_from_int(42); > v = qobject_input_visitor_new(fortytwo); > set_prop(OBJECT(frob), v, "prop", cookie, &err); > visit_free(v); > qobject_unref(fortytwo); > > where set_prop() is the setter you passed to object_property_add(), and > @cookie is the opaque value you passed along with it. > > *Maybe* set_prop() wraps around a simpler setter you can call directly, > or even a struct member you can set directy. QOM does not care. > > And that's my point: QOM does not care for the C layer.
Ok, I think I got it. In practice it depends on how much you want to hide the implementation of the properties and (especially for set-only-before-realize properties) the answer will be "not at all inside the device implementation". So inside the implementation you can always break the information hiding layer if needed (usually for performance or as you point out sanity), and I don't think there is a substantial difference between qdev and QOM. But yeah, I'm willing to concede that QOM the QAPI-- layer of QOM comes first and the C layer comes second. :) Paolo
