Eric Blake <[email protected]> writes: > On 10/02/2015 11:11 AM, Markus Armbruster wrote: > >>>> Why wrap function c_name() in a method? Why not simply call the >>>> function? >>> >>> 'self.c_name()' is shorter than 'c_name(self.name)'. And I already had >>> long lines with that seen[self.c_name()].describe() pattern. >> >> You could also try a local variable: cnam = c_name(self.name). >> >>>> It's method in QAPISchemaEntity only because this lets us add special >>>> cases in a neat way. >>> >>> True, but I _did_ mention in the commit message that I did it for less >>> typing. >>> >>> But as to special cases, yes, I have one in mind (although I have not >>> played with it yet). > >> >> I'm afraid I don't have enough context to grok this late on Friday :) > > Here's another case I have in mind. Right now, we have special code > littered in qapi-types and qapi-visit to track that the > QAPISchemaObjectTypeMember for simple unions is named 'type' in QMP but > 'kind' in C code. Having member.c_name() return 'kind' would simplify > that code.
Yes, but naming it 'type' in C will simplify things even more :) Might make sense as an intermediate step all the same. However, if this is the only reason for having a c_name() member, the member will become superfluous when we clean up the type vs. kind stupidity. > So, what I will do for v7 is rework the patches to independently > implement and use member.c_name() (possibly by also creating a special > subclass of QAPISchemaObjectTypeMember), showing how it makes the > clients easier, and then this patch can also make use of that work.
