Am 22.11.2019 um 15:40 hat Markus Armbruster geschrieben: > Kevin Wolf <kw...@redhat.com> 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