Re: [Qemu-block] Non-flat command line option argument syntax

[Kevin Wolf]

Am 27.02.2017 um 11:27 hat Markus Armbruster geschrieben:
> Markus Armbruster <address@hidden> writes:
> 
> [...]
> > === Dotted keys ===
> >
> > One sufficiently powerful syntax extension already exists: the dotted
> > key convention.  It's syntactically unambiguous only when none of the
> > KEYs involved contains '.'  To adopt it across the board, we'd have to
> > outlaw '.' in KEYs.  QAPI outlaws '.' already, but we have a bunch of
> > QOM properties names with '.'.  We'd have to rename at least the ones
> > that need to be accessible in -object.
> >
> > Dotted keys can't express member names that look like integers.  We'd
> > have to outlaw them at least for the objects that are accessible on the
> > command line.  Once again, QAPI outlaws such names already.  QOM is
> > anarchy when it comes to names, however.
> >
> > The way dotted keys do arrays is inconsistent with how QOM's automatic
> > arrayification (commit 3396590) do them: foo.0 vs. foo[0].  Backward
> > compatibility makes changing the dotted key convention awkward.  Perhaps
> > we can still change QOM.
> 
> 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.
> 
> A natural idea is to interpret "absent in KEY=VALUE,..." as empty.
> After all, removing one key from it removes one member when there are
> more, so why not when there aren't.
> 
> Sadly, it doesn't work: "absent in KEY=VALUE,..." already means
> "optional object/array absent", which isn't the same as "empty
> object/array present".
> 
> 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'm not currently aware of any places where the difference between a
present, but empty array and an absent array is actually significant, so
this is probably the most consistent and useful way to interpret things.

In other words, I agree with your implementation.

> * Absent key means absent, except when the member is visited it means
>   empty.  No way to do absent optional array or object.
> 
> * Likewise, but if the visit is preceeded by a test for presence with
>   visit_optional(), it means absent again.  No way to do present
>   optional empty array or object.  This requires keeping additional
>   state.
> 
> Any bright ideas on how to avoid making things impossible?

I can't see any other option than extending the syntax if we need this.
We can't tell the difference between a string and any other object
description after =, so we would need to make use of reserved characters
in the key name. Maybe just 'foo.array[]' (without any =) for an empty
array or something like that.

Before we introduce anything like this, do we actually need it?

Kevin