On Mon, 05/05 21:09, Eric Blake wrote: > On 05/05/2014 07:30 PM, Fam Zheng wrote: > > >> NAME: { 'type': TYPE, 'default': DEFAULT } > >> > >> where > >> > >> NAME: { 'type': TYPE } > >> > >> can be abbreviated to > >> > >> NAME: TYPE > > > > > In data definition, we allow inline sub-structure: > > > > { 'type': 'VersionInfo', > > 'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'}, > > 'package': 'str'} } > > > > If we allow properties as a dict, we need to disambiguate properly from the > > above case. Proposing: > > > > MAGIC: { 'name': NAME, 'type: TYPE, 'default': DEFAULT } > > Oh, good catch. The alternative is to drop all instances of inline > sub-structs. Searching for 'data.*{.*{', I found only VersionInfo and > PciBridgeInfo; I then did a full manual search of qapi-schema.json and > only found the additional instance of PciDeviceInfo where the sub-struct > is not on the same line as the initial { of the 'data'. Just getting > rid of inlined sub-structs may be quite feasible.
Sounds good. > > On a related vein, there are a number of types that aren't merely a > string name. For example: > > { 'command': 'migrate-set-capabilities', > 'data': { 'capabilities': ['MigrationCapabilityStatus'] } } > > and similar, where we have an array type rather than a raw string type > name. But at least with that, NAME: { 'type': [ 'array' ] } is still a > reasonable parse. > > The problem with MAGIC:{'name'...} is that you need to express more than > one parameter, but as a dict, you can't reuse the same MAGIC more than > once. That is: > > 'data': { MAGIC : { 'name': 'qemu', 'type': { 'major'...} }, > MAGIC : { 'name': 'package', 'type', 'str' } } } Right. Not necessarily better than dropping inline structure, just another idea: 'data' { '@arg_with_properties': { 'type': 'str' }, '*simple_optional': 'str', '@optional_full': { 'type': 'int', 'default': 1 }, 'the_most_common_form': 'bool', 'inline_structure': { 'major': ...} } Where '@' is a prefix for property dictionary similar to, while exclusive with, optional mark '*'. > > proves that you have to have two distinct MAGIC in the same 'data', so > '' for both is out. > > > > > Where MAGIC should NOT be something that is a valid NAME from current > > schema. > > Some ideas: > > > > - Special string, that has invalid chars as a identifier, like '*', '%', > > '&', > > etc, or simply an empty str ''. > > Of course we need to enforce the checking and distinguishing in > > scripts/qapi-types.py. > > > > - Non-string: current NAME must be a string, any type non-string could be > > distinguished from NAME, like number, bool, null, []. But its meaning > > could > > be confusing to reviewer. > > > > - Special symbol: we can define a dedicate symbol for this, like the > > literal > > TYPE, in the schema. But this way we deviate more from JSON. > > Also, while we aren't strict JSON, it's nice that we're still fairly > close to JSON5, and worth keeping that property. > > > > > Personally, I think empty str '' makes more sense for me. What do you think? > > > > At this point, I'm leaning towards dropping support for unnamed inlined > sub-structs. Yes. That said, I'm also leaning towards dropping, that keeps things simple. Fam