Kevin Wolf <kw...@redhat.com> writes:
> One question in addition to what Eric already asked:
>
> Am 02.04.2015 um 19:29 hat Markus Armbruster geschrieben:
>> +{ 'enum': 'SchemaMetaType',
>> + 'data': [ 'builtin', 'enum', 'array', 'object', 'alternate',
>> + 'command', 'event' ] }
>> +
>> +{ 'type': 'SchemaInfoBase',
>> + 'data': { 'name': 'str', 'meta-type': 'SchemaMetaType' } }
>> +
>> +{ 'enum': 'JSONPrimitiveType',
>> + 'data': [ 'str', 'int', 'number', 'bool', 'null' ] }
>> +
>> +{ 'type': 'SchemaInfoBuiltin',
>> + 'data': { 'json-type': 'JSONPrimitiveType' } }
>> +
>> +{ 'type': 'SchemaInfoEnum',
>> + 'data': { 'values': ['str'] } }
>> +
>> +{ 'type': 'SchemaInfoArray',
>> + 'data': { 'element-type': 'str' } }
>> +
>> +{ 'alternate': 'Value',
>> + 'data': { 'int': 'int', 'number': 'number', 'str': 'str', 'bool':
>> bool' } }
>> +
>> +{ 'type': 'SchemaInfoObjectMember',
>> + 'data': { 'name': 'str', 'type': 'str', '*default': 'Value' } }
>> +# @default's type must match @type
>> +# can only default simple types, not objects or arrays
>> +
>> +{ 'type': 'SchemaInfoObjectVariant',
>> + 'data': { 'case': 'str',
>> + 'members': [ 'SchemaInfoObjectMember' ] } }
>> +
>> +{ 'type': 'SchemaInfoObject',
>> + 'data': { 'members': [ 'SchemaInfoObjectMember' ],
>> + '*discriminator': 'str',
>> + '*variants': [ 'SchemaInfoObjectVariant' ] } }
>> +
>> +{ 'type': 'SchemaInfoAlternate',
>> + 'data': { 'members': [ 'SchemaInfoObjectMember' ] } }
>
> I'm not sure if I understand correctly how this one works. My guess
> would be this:
>
> - The elements in members describe the different variants. That is, you
> choose of the members, whereas in SchemaInfoObject all of the members
> exist.
Correct.
> Perhaps they should be using different names then?
I simply reused SchemaInfoObjectMember. Similar to how C's struct and
union share member declaration syntax.
> - The type (= discriminator) of a variant is indirectly specified by the
> 'type' of the SchemaInfoObjectMember: This is a QAPI type, but the
> JSON type can be resolved by checking 'meta-type' of the QAPI type
> (and SchemaInfoBuiltin if necessary)
Correct.
The introspection schema doesn't reflect the "the variant's JSON types
are all different" rule.
> - The 'name' in SchemaInfoObjectMember could be the key name of the
> variant in the alternate definition. However, this name isn't used
> anywhere in the QMP protocol, so maybe it is better kept internal.
> 'name' isn't optional, though.
This is actually a more convincing argument for having a separate
SchemaInfoAlternateMember.
> - The 'default' of SchemaInfoObjectMember must be omitted.
Likewise.
> Do I understand the intention reasonably right? If so, maybe it would be
> better to use a separate type for alternate variants.
I'll certainly consider that for the next iteration.
Thanks!
