[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for str
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members |
Date: |
Fri, 22 Nov 2019 17:12:15 +0100 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
Am 22.11.2019 um 15:40 hat Markus Armbruster geschrieben:
> 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.
That definition wasn't a great idea, I'm afraid. :-(
But "default is QNull" is still acceptable behaviour for "not
specified" if the client doesn't need to know what the default is.
> >> > 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.
Not loss of expressiveness, but loss of consistency.
> 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 }
I assume this means: 'optional' defaults to true if 'default' is
present, and to false if 'default' is absent. (It's an example of a
default that can't be expressed in the schema.)
Works for me.
Kevin
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Markus Armbruster, 2019/11/14
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Markus Armbruster, 2019/11/21
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Eric Blake, 2019/11/21
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Markus Armbruster, 2019/11/21
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Eric Blake, 2019/11/21
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Markus Armbruster, 2019/11/22
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Kevin Wolf, 2019/11/22
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members, Markus Armbruster, 2019/11/22
- Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members,
Kevin Wolf <=