Eric Blake <ebl...@redhat.com> writes:
> On 03/27/2015 01:52 AM, Markus Armbruster wrote:
>> One more...
>>
>> Eric Blake <ebl...@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.
No objections. The churn will be a bit annoying with git-blame, but I'd
prefer that to continuing with confusing terminology.
>>
>> 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
Indeed.
The odd in-between-ness of alternate here is additional justification
for you separating it from union.
