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

[Markus Armbruster <armbru@redhat.com>]

Fam Zheng <famz@redhat.com> writes:

> 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 '*'.

If we decide to keep the '*' sigil, we can add more.  Two similar
violations of the "no syntax beyond JSON" design rule aren't really
worse than one.

That said, I dislike all sigils equally :)

[...]