Re: [Qemu-devel] [PATCH v8 10/18] qapi: Move union tag quirks into subclass

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 10/13/2015 06:10 AM, Markus Armbruster wrote:
>> Eric Blake <address@hidden> writes:
>> 
>>> Right now, simple unions have a quirk of using 'kind' in the C
>>> struct to match the QMP wire name 'type'.  This has resulted in
>>> messy clients each doing special cases.  While we plan to
>>> eventually rename things to match, it is better in the meantime
>>> to consolidate the quirks into a special subclass, by adding a
>>> new member.c_name() function.  This will also make it easier
>>> for reworking how alternate types are laid out in a future
>>> patch.  Use the new c_name() function where possible.
>> 
>> Terminology: "the new c_name() method".
>> 
>> I don't like having both function c_name() and method c_name(), because
>> it's very easy to use the function when you should use the method, and
>> the mistakes will make things break only rarely, so they can go
>> undetected easily.  I'm okay with this patch only because you assure me
>> the whole thing is temporary: "# TODO Drop this class once we no longer
>> have the 'type'/'kind' mismatch".
>
> Hmm. Even after my type/kind fix is in, my local tree doesn't (yet)
> remove uses of c_name(), because of its shorter typing.  But you are
> correct that once the rename is in and the temporary
> QAPISchemaObjectTypeUnionTag is deleted, then there is no longer a
> difference between member.c_name() and the longer c_name(member.name).
>
> On the other hand, my patch subset C adds a member.c_type() function
> which is required for use on simplified alternate layout, because it is
> not always the same as member.type.c_type() or c_type(member.type.name).

Can't say how I like it until I reviewed it :)

> As it is, we already have cases where c_name(entity.name) is not the
> same as entity.c_name(), so we already have the confusion of when to use
> the global function vs. the member function.

They are:

* QAPISchemaBuiltinType.c_name() returns its argument instead

* QAPISchemaObjectType.c_name() additionally asserts "not implicit".

* QAPISchemaObjectTypeUnionTag.c_name() returns 'kind' instead, but
  that'll go away.

Anything else?

> Is it worth renaming things so that the global function and member
> functions have different names? If so, which one would be renamed, and
> to what?

Renaming one of them can perhaps make misuse of the function stand out a
bit more.

The only way I can see to keep obvious use of the interface correct is
getting rid of the function entirely.  Involves passing objects instead
of names around, then calling the objects' method instead of passing the
name to the function.  Can't say whether a suitable object always exists
without trying it.

>>> No change to generated code.
>>>
>>> Signed-off-by: Eric Blake <address@hidden>
>>>
>>> ---
>> 
>> v8: use + instead of interpolation in a few places, rebase to simpler
>> .is_implicit(), use .c_name() more.
>
> Whoops, forgot to 'git commit --amend' this one.  Looks like you are
> also viewing interdiffs, though, which makes me feel better about how
> the series is progressing.

When I expect only small and scattered change, I like to feed patches to
ediff :)

>>> +++ b/scripts/qapi-commands.py
>>> @@ -32,8 +32,8 @@ def gen_call(name, arg_type, ret_type):
>>>      if arg_type:
>>>          for memb in arg_type.members:
>>>              if memb.optional:
>>> -                argstr += 'has_%s, ' % c_name(memb.name)
>>> -            argstr += '%s, ' % c_name(memb.name)
>>> +                argstr += 'has_' + memb.c_name() + ', '
>>> +            argstr += memb.c_name() + ', '
>> 
>> I like to use + instead of % in sufficiently simple cases myself.  Not
>> sure this is one.  See also change to gen_params() below.
>
>>> @@ -1555,8 +1567,8 @@ def gen_params(arg_type, extra):
>>>          ret += sep
>>>          sep = ', '
>>>          if memb.optional:
>>> -            ret += 'bool has_%s, ' % c_name(memb.name)
>>> -        ret += '%s %s' % (memb.type.c_type(is_param=True), 
>>> c_name(memb.name))
>>> +            ret += 'bool has_' + memb.c_name() + sep
>>> +        ret += '%s %s' % (memb.type.c_type(is_param=True), memb.c_name())
>>>      if extra:
>>>          ret += sep + extra
>>>      return ret
>> 
>> New hunk in v8, to remain consistent with gen_call().
>> 
>> I doubt replacing literal ', ' by sep is making things clearer.
>
> Fair enough - if there is reason for respin, I can undo the changes to
> using '+'.
>
>>> @@ -1604,7 +1616,7 @@ def gen_visit_fields(members, prefix='', 
>>> need_cast=False, skiperr=False):
>>>      visit_type_%(c_type)s(v, %(cast)s&%(prefix)s%(c_name)s, "%(name)s", 
>>> %(errp)s);
>>>  ''',
>>>                       c_type=memb.type.c_name(), prefix=prefix, cast=cast,
>>> -                     c_name=c_name(memb.name), name=memb.name,
>>> +                     c_name=memb.c_name(), name=memb.name,
>>>                       errp=errparg)
>>>          ret += gen_err_check(skiperr=skiperr)
>> 
>> New hunks in v8.  Do you change from function c_name() to method
>> .c_name() Just for consistency, or is there a more serious reason?
>
> It matters the most in qapi-type's gen_union(); everywhere else, it is
> just for consistency and less typing.
>
> What is the plan of attack on this one - will I need to respin a v9?

I'll answer this in my reply to PATCH 15.