Re: [RFC PATCH] qobject: Rewrite implementation of QDict for in-order traversal

[Daniel P . Berrangé]

On Mon, Jul 11, 2022 at 11:32:35AM +0100, Peter Maydell wrote:
> On Fri, 8 Jul 2022 at 12:01, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > What alternative options do we have for addressing this scenario.
> >
> > I can think of
> >
> >   - Auto-create array elements, if seeing an element set before length.
> >
> >     This is based on the theory that 'len-PROP' field is largely
> >     redundant. It is only needed if you want to create a sparse
> >     array, with empty elements /after/ the last one explicitly
> >     set, or if you want to get error reporting for an app setting
> >     element 3 after saying it wanted a 2 element list. IMHO the
> >     error reporting benefit is dubious, because the error scenario
> >     only exists because we made the app set this redundant 'len-PROP'
> >     attribute. Does anything actually need the 'sparse array'
> >     facility ?
> 
> I'm pretty sure that nothing needs sparse array elements like
> that. The major reason for the len-PROP field is an implementation
> one: because there is currently no way for a QOM object to
> say "call this method if somebody tries to set a non-existent
> property", the way array properties work is that the 'set'
> method for the len-PROP property is the place where we then
> add the PROP[0], PROP[1], ... properties.

Ahhh, I see what you mean. I totally missed this subtle detail.

IIUC, there's essentially no such thing as array properties
in QOM. 'prop[0]', 'prop[1]', 'prop[2]', etc are all simply
scalar properties from QOM's, that just happen to follow a
common naming scheme, but QOM doesn't care about that.

> If we either had a "call this for any property set/get attempt
> where there is no specific method set" or else had array
> properties supported by the core QOM code, we could avoid
> having to set len-PROP first.

Techically arrays are already supported at the core QOM level, because
you can use any QAPI type as a property.  The authz/list.c object
has a 'rules' property that is an array of QAuthzListRule objects:

  { 'struct': 'AuthZListProperties',
    'data': { '*policy': 'QAuthZListPolicy',
              '*rules': ['QAuthZListRule'] } }

At the time I wrote that, we couldn't express it on the CLI though,
without using JSON syntax for -object. I don't think we've ever
made it possible to use the opts_visitor with non-scalar properties
though.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|