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

[Eric Blake]

On 05/05/2014 05:06 AM, Markus Armbruster wrote:

>>
>>     { 'command': 'block-commit',
>>       'data': { 'device': 'str', '*base': 'str', 'top': 'str',
>>                 '*speed': 'int' },
>>       'defaults': {'base': 'earthquake', 'speed': 100 } }
>>

> 
> Can we keep a parameter's properties together?  Perhaps like this:
> 
>     NAME: { 'type': TYPE, 'default': DEFAULT }
> 
> where
> 
>     NAME: { 'type': TYPE }
> 
> can be abbreviated to
> 
>     NAME: TYPE

I like it.  It also means:

data: { '*foo': { 'type': 'str', 'default': 'hello' } }

is invalid - a defaulted argument is NOT spelled '*foo' but merely 'foo'.

> 
> and
> 
>     NAME: { 'type': TYPE, 'default': null }
> to
> 
>     NAME-PREFIXED-BY_ASKTERISK: TYPE
> 
> if we think these abbreviations enhance schema readability enough to be
> worthwhile.  The first one does, in my opinion. but I'm not so sure
> about the second one.

Or, putting the question in reverse, you are asking if:

data: { '*foo': 'str' }

can blindly be rewritten into:

data: { 'foo': { 'type': 'str', 'default': null } }

and the rest of the introspection use the fact that 'default':null
implies that the argument is optional but has no specified default, and
therefore still needs the has_foo magic.

As you say, it's a bit more of a stretch, but does make introspection
nice (introspection already has to deal with leading '*' to turn it into
something nicer to pass over the wire - if we ever get introspection
working).  I'd have to see it actually coded up to decide for sure if it
turned out to be a net win.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature