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. 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? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature