On 03/27/2015 01:52 AM, Markus Armbruster wrote:
> One more...
> 
> Eric Blake <eblake@redhat.com> writes:
> 
> [...]
>> diff --git a/scripts/qapi.py b/scripts/qapi.py
>> index 90eb3bc..5d0dc91 100644
>> --- a/scripts/qapi.py
>> +++ b/scripts/qapi.py
> [...]
>> @@ -560,12 +585,22 @@ def type_name(name):
>>          return c_list_type(name[0])
>>      return name
>>
>> -enum_types = []
>> -struct_types = []
>> -union_types = []
>> +def add_name(name, info, meta, implicit = False):
>> +    global all_names
>> +    if name in all_names:
>> +        raise QAPIExprError(info,
>> +                            "%s '%s' is already defined"
>> +                            %(all_names[name], name))
> 
> We say "struct 'Foo'", and expect the user to know that 'struct' means
> 'complex type'.  It'll do, it's just a development tool.

In fact, I considered making it "type 'Foo'", to match that the item is
declared with { 'type':'Foo' ...} and not { 'struct':'Foo' ...}.  But
type is an ambiguous word.  I'm half tempted to do a global
search-and-replace of s/'type'/'struct'/ in the json files, since
'union' is also a type.  Obviously as its own patch.

> 
> I'm not really happy with 'complex type', though.  Isn't a union type
> complex, too?  Anyway, we can clean up our confused terminology later;
> this series is long enough.

Hmm. If I _do_ the global rename, then we have a nice hierarchy:

type  -  simple type: built-in, enum
      -  alternate
      -  complex type: struct, union

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org