Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for optional parameters

[Fam Zheng]

On Mon, 05/05 21:09, Eric Blake wrote:
> On 05/05/2014 07:30 PM, Fam Zheng wrote:
> 
> >>     NAME: { 'type': TYPE, 'default': DEFAULT }
> >>
> >> where
> >>
> >>     NAME: { 'type': TYPE }
> >>
> >> can be abbreviated to
> >>
> >>     NAME: TYPE
> 
> > 
> > In data definition, we allow inline sub-structure:
> > 
> > { 'type': 'VersionInfo',
> >   'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'},
> >            'package': 'str'} }
> > 
> > If we allow properties as a dict, we need to disambiguate properly from the
> > above case. Proposing:
> > 
> >     MAGIC: { 'name': NAME, 'type: TYPE, 'default': DEFAULT }
> 
> Oh, good catch.  The alternative is to drop all instances of inline
> sub-structs.  Searching for 'data.*{.*{', I found only VersionInfo and
> PciBridgeInfo; I then did a full manual search of qapi-schema.json and
> only found the additional instance of PciDeviceInfo where the sub-struct
> is not on the same line as the initial { of the 'data'.  Just getting
> rid of inlined sub-structs may be quite feasible.

Sounds good.

> 
> On a related vein, there are a number of types that aren't merely a
> string name.  For example:
> 
> { 'command': 'migrate-set-capabilities',
>   'data': { 'capabilities': ['MigrationCapabilityStatus'] } }
> 
> and similar, where we have an array type rather than a raw string type
> name.  But at least with that, NAME: { 'type': [ 'array' ] } is still a
> reasonable parse.
> 
> The problem with MAGIC:{'name'...} is that you need to express more than
> one parameter, but as a dict, you can't reuse the same MAGIC more than
> once.  That is:
> 
> 'data': { MAGIC : { 'name': 'qemu', 'type': { 'major'...} },
>           MAGIC : { 'name': 'package', 'type', 'str' } } }

Right.

Not necessarily better than dropping inline structure, just another idea:

  'data' { '@arg_with_properties': { 'type': 'str' },
           '*simple_optional': 'str',
           '@optional_full': { 'type': 'int', 'default': 1 },
           'the_most_common_form': 'bool',
           'inline_structure': { 'major': ...} }

Where '@' is a prefix for property dictionary similar to, while exclusive with,
optional mark '*'.

> 
> proves that you have to have two distinct MAGIC in the same 'data', so
> '' for both is out.
> 
> > 
> > Where MAGIC should NOT be something that is a valid NAME from current 
> > schema.
> > Some ideas:
> > 
> >  - Special string, that has invalid chars as a identifier, like '*', '%', 
> > '&',
> >    etc, or simply an empty str ''.
> >    Of course we need to enforce the checking and distinguishing in
> >    scripts/qapi-types.py.
> > 
> >  - Non-string: current NAME must be a string, any type non-string could be
> >    distinguished from NAME, like number, bool, null, []. But its meaning 
> > could
> >    be confusing to reviewer.
> > 
> >  - Special symbol: we can define a dedicate symbol for this, like the 
> > literal
> >    TYPE, in the schema. But this way we deviate more from JSON.
> 
> Also, while we aren't strict JSON, it's nice that we're still fairly
> close to JSON5, and worth keeping that property.
> 
> > 
> > Personally, I think empty str '' makes more sense for me. What do you think?
> > 
> 
> At this point, I'm leaning towards dropping support for unnamed inlined
> sub-structs.

Yes. That said, I'm also leaning towards dropping, that keeps things simple.

Fam