Eric Blake <ebl...@redhat.com> writes:
> On 02/27/2017 04:27 AM, Markus Armbruster wrote:
>> Design flaw: there is no good way to denote an empty array or object
>> other than the root object.
>>
>> Empty KEY=VALUE,... is valid and results in an empty root object.
>>
>> Presence of a KEY that contains periods results in additional non-root
>> objects or arrays. For instance, KEY a.b.c results in root object
>> member "a" that has member "b" that has (scalar) member "c".
>>
>> These additional objects and arrays all have at least one member, by
>> construction.
>>
>> Begs the question how to denote an empty object or array other than the
>> root.
>
> If a.b.c=1 means root object has member "a" with child object "b", and
> object "b" has key "c" with scalar value, I suppose we could allow:
>
> a.b,
>
> (with no =val) to mean root object "a" has an empty child "b"
> (indeterminate if "b" is an object or a list) - but only if we don't
> allow the 'foo' => 'foo=on' magic already in use by QemuOpts. And you
> still have to figure out how to choose empty list vs. empty object.
What if "b" is an alternate? Should it be [], {} or true?
>> Without additional syntax, all we can do is choose what exactly to make
>> impossible:
>>
>> * Absent key means absent, period. No way to do empty array or object.
>> This is what I implemented.
>
> I lean towards this meaning. It should generally possible to allow an
> empty object/list to mean the same thing as an optional omitted
> object/list in all contexts - so omitting KEY=VALUE for a list means you
> are omitting the list, but the omitted list behaves the same as an
> explicitly empty one would have done (even though dotted syntax doesn't
> have an easy way to express an explicit empty list).
It certainly feels "natural" (whatever that may mean) to imagine QAPI
used this way, but nothing stops users from making "absent" and "empty"
mean different things.
Say we have a configurable object in QEMU that sports an arbitrary
number of configurable sub-objects. Like BlockdevOptionsBlkdebug has
BlkdebugInjectErrorOptions. Except in our case, and just to make my
point, the sub-object configuration has only optional members, because a
perfectly sensible default configuration exists. Let's further assume
that one sub-object in default configuration is not the same as zero sub
objects.
Now let's configure a single sub-object that is completely default. In
JSON, that's
"sub-objects": [ {} ]
With dotted keys, you can't express it.
