qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for o


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for optional parameters
Date: Tue, 06 May 2014 17:09:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 05/06/2014 03:55 AM, Markus Armbruster wrote:
>
>>> Keeping the input file easy to write, and more compact than what
>>> introspection will output, is a fine tradeoff in my book (easier to
>>> maintain if there is less to type; while still having a well-defined
>>> conversion to the formal output form).
>> 
>> Unlike the other sugared form, this one adds syntax beyond JSON, namely
>> in some (but not all) member names, and that makes it a bit harder to
>> stomach for me.
>
> JSON has no requirement that a 'name':'value' object limit the 'name'
> portion to just valid identifier characters.  But I do see your point
> about the fact that we are parsing a sigil of '*' as the first character
> of 'name' as sugar.
>
>> 
>> Whether it's worthwhile depends on how common the case "optional, no
>> default" turns out to be.  Wait and see.
>
> It's already VERY common - every optional variable already uses the
> syntax.  The question is rather: how many optional variables will be
> rewritten to express a default value, vs. those that can be left alone
> because the default value is good enough.

That's precisely the question.

I like explicit defaults in the schema, they're fine documentation.
They can also simplify code.

>                                            A global search-and-replace
> could rewrite the entire file to the new syntax for optional variables,
> and we could enforce the new more verbose style going forward, but is
> the churn worth it?

Wait and see how many optionals pick up defaults.  The more do, the less
churn.



reply via email to

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