Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 22.11.2019 um 08:29 hat Markus Armbruster geschrieben:
>> > At any rate, your counterpoint is taken - whatever we pick, we'll want
>> > to make sure that introspection can expose semantics, and whether we
>> > can make '*' redundant with some other form of longhand in the qapi
>> > language is in part determined by whether we also reflect that through
>> > introspection.
>> 
>> Introspection has the true member name, without the '*' prefix.
>> 
>> We'll also want to avoid unnecessary compromises on QAPI schema
>> expressiveness.  If we use null to mean "schema does not specify
>> behavior when member is absent", we can't use it to mean "absent member
>> behaves like the value null".  A bit of a blemish, but I think it's a
>> tolerable one.
>
> If you want an example for an option that defaults to null, take the
> backing option of BlockdevOptionsGenericCOWFormat.
>
> What is the reason for even considering limiting the expressiveness? Do
> you think that an additional 'optional' bool, at least for those options
> that don't have a default, would be so bad in the longhand form? Or
> keeping '*' even in the longhand form, as suggested below.

Well, one reason is this:

    ##
    # @SchemaInfoObjectMember:
    #
    # An object member.
    #
    # @name: the member's name, as defined in the QAPI schema.
    #
    # @type: the name of the member's type.
    #
    # @default: default when used as command parameter.
    #           If absent, the parameter is mandatory.
    #           If present, the value must be null.  The parameter is
    #           optional, and behavior when it's missing is not specified
    #           here.
    #           Future extension: if present and non-null, the parameter
    #           is optional, and defaults to this value.
    #
    # Since: 2.5
    ##

If we want to be able to express the difference between "behavior when
absent is not specified here" and "absent behaves like value null", then
we need to somehow add that bit of information here.

Could use a feature.  Features are not yet implemented for members, but
we need them anyway.

>> >                 If that means that keeping '*' in the longhand form of
>> > optional members (whether or not those members have a default value),
>> > then so be it.
>> 
>> I believe both
>> 
>>     '*KEY': { 'type': ARG': 'default': null }
>> 
>> and
>> 
>>     'KEY': { 'type': ARG': 'default': null }
>> 
>> are viable longhand forms for '*KEY': 'ARG'.
>> 
>> I prefer the latter, but I'm open to arguments.
>
> If you go for the former, then you certainly want to use absent
> 'default' to indicate no default, and allow a QNull default with
> 'default': null.
>
> The only reason to abuse 'default': null for no default is that you
> can't distinguish optional and non-optional if you use 'KEY' for both
> instead of 'KEY' for mandatory and '*KEY' for optional.
>
> So while I understand and to some degree share your dislike for the '*'
> prefix, I think I cast my pragmatic vote for:
>
> mandatory:                   'KEY':  { 'type': 'ARG' }
> optional without a default:  '*KEY': { 'type': 'ARG' }
> optional with QNull default: '*KEY': { 'type': 'ARG', 'default': null }

The last one could also be     'KEY': { 'type': 'ARG', 'default': null }
without loss of expressiveness.

Differently ugly.

Here's yet another idea.  For the "absent is not specified here" case,
use

    'KEY': { 'type': 'ARG', optional: true }
    '*KEY': 'ARG'

For the "absent defaults to DEFVAL" case, use

    'KEY': { 'type': 'ARG', optional: true, 'default': DEFVAL }
    'KEY': { 'type': 'ARG', 'default': DEFVAL }