qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] qapi: allow flat unions with empty branches


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 1/2] qapi: allow flat unions with empty branches
Date: Tue, 15 May 2018 19:40:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 05/15/2018 02:01 AM, Markus Armbruster wrote:
>
>>>> QAPI language design alternatives:
>>>>
>>>> 1. Having unions cover all discriminator values explicitly is useful.
>
>>>> 2. Having unions repeat all the discriminator values explicitly is not
>>>> useful.  All we need is replacing the code enforcing that by code
>>>> defaulting missing ones to the empty type.
>>>>
>>>> 3. We can't decide, so we do both (this patch).
>>>>
>
>> I'd prefer a more opinionated design here.
>>
>> Either we opine making people repeat the tag values is an overall win.
>> Then make them repeat them always, don't give them the option to not
>> repeat them.  Drop this patch.  To reduce verbosity, we can add a
>> suitable way to denote a predefined empty type.
>>
>> Or we opine it's not.  Then let them not repeat them, don't give them
>> the option to make themselves repeat them.  Evolve this patch into one
>> that makes flat union variants optional and default to empty.  If we
>> later find we still want a way to denote a predefined empty type, we can
>> add it then.
>>
>> My personal opinion is it's not.
>
> I followed the arguments up to the last sentence, but then I got lost
> on whether you meant:
>
> This patch is not an overall win, so let's drop it and keep status quo
> and/or implement a way to write 'branch':{} (option 1 above)
>
> or
>
> Forcing repetition is not an overall win, so let's drop that
> requirement by using something similar to this patch (option 2 above)
> but without adding a 'partial-data' key.

Sorry about that.  I meant the latter.

> But you've convinced me that option 3 (supporting a compact branch
> representation AND supporting missing branches as defaulting to an
> empty type) is more of a maintenance burden (any time there is more
> than one way to write something, it requires more testing that both
> ways continue to work) and thus not worth doing without strong
> evidence that we need both ways (which we do not currently have).



reply via email to

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