Eric Blake <ebl...@redhat.com> writes:
> We were previously creating all unions with an empty list for
> local_members. However, it will make it easier to unify struct
> and union generation if we include the generated tag member in
> local_members. That way, we can have a common code pattern:
> visit the base (if any), visit the local members (if any), visit
> the variants (if any). The local_members of a flat union
> remains empty (because the discriminator is already visited as
> part of the base). Then, by visiting tag_member.check() during
> AlternateType.check(), we no longer need to call it during
> Variants.check().
Moving tag_member.check() could perhaps be a separate patch. But it's
okay as is.
> The various front end entities now exist as follows:
> struct: optional base, optional local_members, no variants
> simple union: no base, one-element local_members, variants with tag_member
> from local_members
> flat union: base, no local_members, variants with tag_member from base
> alternate: no base, no local_members, variants
Ultimately, I'd like a single object type. Then this becomes:
object: optional base, optional local_members,
optional variants with tag_member from base or local_members
alternate: only variants
In both cases, I view the tag member as belonging to the outer
container, not variants:
object stores it like any other member, and variants.tag_member
merely identifies the member that serves as tag
alternate doesn't store it member in self, but simply uses
self.variants.tag_member instead.
Perhaps QAPISchemaObjectTypeVariants should be inlined.
Just rambling, the commit message is fine as is.
> With the new local members, we require a bit of finesse to
> avoid assertions in the clients.
>
> No change to generated code.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
Patch looks good.
