qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v9 10/27] qapi: Track simple union tag in object


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v9 10/27] qapi: Track simple union tag in object.local_members
Date: Wed, 04 Nov 2015 12:02:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eric Blake <address@hidden> 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 <address@hidden>

Patch looks good.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]