Eric Blake <ebl...@redhat.com> writes:
> On 05/05/2014 11:34 AM, Markus Armbruster wrote:
>>>
>>> Or, putting the question in reverse, you are asking if:
>>>
>>> data: { '*foo': 'str' }
>>>
>>> can blindly be rewritten into:
>>>
>>> data: { 'foo': { 'type': 'str', 'default': null } }
>>>
>>> and the rest of the introspection use the fact that 'default':null
>>> implies that the argument is optional but has no specified default, and
>>> therefore still needs the has_foo magic.
>>>
>>> As you say, it's a bit more of a stretch, but does make introspection
>>> nice (introspection already has to deal with leading '*' to turn it into
>>> something nicer to pass over the wire - if we ever get introspection
>>> working). I'd have to see it actually coded up to decide for sure if it
>>> turned out to be a net win.
>>
>> Glad you mention introspection; I didn't think of it.
>>
>> The "an asterisk at the beginning of a name is not part of the name, but
>> means the parameter is optional" thing is a deviation from our usual
>> design rule against parsing strings in addition to JSON. My proposal to
>> make the "is optional" property an ordinary JSON member straightens this
>> out.
>>
>> The bit I'm not sure about is whether we want to keep the
>> NAME-PREFIXED-BY-ASKTERISK: TYPE form as syntactic sugar.
>
> Keeping it as sugar in the input .json files seems reasonable.
>
> Exposing it as sugar in introspection is a bad idea.
>
> 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.
Whether it's worthwhile depends on how common the case "optional, no
default" turns out to be. Wait and see.
>> Keeping the TYPE: NAME form as sugar makes sense to me, because it cuts
>> noise in the schema while adding no syntax beyond JSON.
>
> Exactly - the point of syntactic sugar is to have a short form for
> common usage, while having the full form when full expressiveness is
> needed. The .json schema files are internal use only; the introspection
> QMP command is not yet written but can adapt to the ideas in this thread.
>
>>
>> The schema parser desugars its input. Sugaring schema introspection
>> output makes no sense to me, because all that accomplishes is
>> introspection users have to duplicate the schema parser's desugaring.
>
> I think we're on the same page, then.
:)
