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

[Eric Blake]

On 05/05/2014 11:34 AM, Markus Armbruster wrote:
>>
>> 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.
> 
> Glad you mention introspection; I didn't think of it.
> 
> The "an asterisk at the beginning of a name is not part of the name, but
> means the parameter is optional" thing is a deviation from our usual
> design rule against parsing strings in addition to JSON.  My proposal to
> make the "is optional" property an ordinary JSON member straightens this
> out.
> 
> The bit I'm not sure about is whether we want to keep the
> NAME-PREFIXED-BY-ASKTERISK: TYPE form as syntactic sugar.

Keeping it as sugar in the input .json files seems reasonable.

Exposing it as sugar in introspection is a bad idea.

Keeping the input file easy to write, and more compact than what
introspection will output, is a fine tradeoff in my book (easier to
maintain if there is less to type; while still having a well-defined
conversion to the formal output form).

> 
> Keeping the TYPE: NAME form as sugar makes sense to me, because it cuts
> noise in the schema while adding no syntax beyond JSON.

Exactly - the point of syntactic sugar is to have a short form for
common usage, while having the full form when full expressiveness is
needed.  The .json schema files are internal use only; the introspection
QMP command is not yet written but can adapt to the ideas in this thread.

> 
> The schema parser desugars its input.  Sugaring schema introspection
> output makes no sense to me, because all that accomplishes is
> introspection users have to duplicate the schema parser's desugaring.

I think we're on the same page, then.

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

signature.asc
Description: OpenPGP digital signature