qemu-block
[Top][All Lists]
Advanced

[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 11:25:19 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

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.

> >                 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 }

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]