[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 05/17] qapi: pass QAPISchemaModule to visit_module instead
Re: [PATCH v3 05/17] qapi: pass QAPISchemaModule to visit_module instead of str
Wed, 20 Jan 2021 10:02:55 -0600
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
On 1/20/21 6:07 AM, Markus Armbruster wrote:
> John Snow <firstname.lastname@example.org> writes:
>> Modify visit_module to pass the module itself instead of just its
>> name. This allows for future patches to centralize some
>> module-interrogation behavior within the QAPISchemaModule class itself,
>> cutting down on duplication between gen.py and schema.py.
> We've been tempted to make similar changes before (don't worry, I'm not
> building a case for "no" here).
> When I wrote the initial version of QAPISchemaVisitor (commit 3f7dc21be,
> 2015), I aimed for a loose coupling of backends and the internal
> representation. Instead of
> def visit_foo(self, foo):
> where @foo is a QAPISchemaFooBar, I wrote
> def visit_foo_bar(self, name, info, [curated attributes of @foo]):
> In theory, this is nice: the information exposed to the backends is
> obvious, and the backends can't accidentally mutate @foo.
> In practice, it kind of failed right then and there:
> def visit_object_type(self, name, info, base, members, variants):
> We avoid passing the QAPISchemaObjectType (loose coupling, cool!), only
> to pass member information as List[QAPISchemaObjectTypeMember].
> Morever, passing "curated atttibutes" has led to visit_commands() taking
> a dozen arguments. Meh.
> This had made Eric and me wonder whether we should write off the
> decoupling idea as misguided, and just pass the object instead of
> "curated attributes", always. Thoughts?
I'm open to the idea of passing just the larger object instead of the
curated list of relevant attributes. It's a bit more coupling, but I
don't see any of our qapi code being reused outside its current scope
where the extra coupling will bite us. But I'm not volunteering for the
refactoring work, because I'm not an expert on python typing hints. If
consolidating parameters into the larger object makes for fewer
parameters and easier typing hints, I'm assuming the work can be done as
part of static typing; but if leaving things as they currently are is
manageable, that's also fine by me.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[PATCH v3 07/17] qapi/gen: Replace ._begin_system_module(), John Snow, 2021/01/19
[PATCH v3 11/17] qapi: centralize the built-in module name definition, John Snow, 2021/01/19
[PATCH v3 04/17] qapi/gen: inline _wrap_ifcond into end_if(), John Snow, 2021/01/19
[PATCH v3 12/17] qapi/gen: write _genc/_genh access shims, John Snow, 2021/01/19
[PATCH v3 16/17] qapi: type 'info' as Optional[QAPISourceInfo], John Snow, 2021/01/19
[PATCH v3 10/17] qapi/gen: Combine ._add_[user|system]_module, John Snow, 2021/01/19
- [PATCH v3 00/17] qapi: static typing conversion, pt1.5, John Snow, 2021/01/19
- [PATCH v3 03/17] qapi/main: handle theoretical None-return from re.match(), John Snow, 2021/01/19
- [PATCH v3 01/17] qapi/commands: assert arg_type is not None, John Snow, 2021/01/19
- [PATCH v3 06/17] qapi: centralize is_[user|system|builtin]_module methods, John Snow, 2021/01/19
- [PATCH v3 08/17] qapi: use explicitly internal module names, John Snow, 2021/01/19
- [PATCH v3 05/17] qapi: pass QAPISchemaModule to visit_module instead of str, John Snow, 2021/01/19