Eric Blake <ebl...@redhat.com> 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.
