Markus Armbruster <arm...@redhat.com> 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. * 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? [...]
