On 05/05/2014 05:06 AM, Markus Armbruster wrote:
>>
>> { 'command': 'block-commit',
>> 'data': { 'device': 'str', '*base': 'str', 'top': 'str',
>> '*speed': 'int' },
>> 'defaults': {'base': 'earthquake', 'speed': 100 } }
>>
>
> Can we keep a parameter's properties together? Perhaps like this:
>
> NAME: { 'type': TYPE, 'default': DEFAULT }
>
> where
>
> NAME: { 'type': TYPE }
>
> can be abbreviated to
>
> NAME: TYPE
I like it. It also means:
data: { '*foo': { 'type': 'str', 'default': 'hello' } }
is invalid - a defaulted argument is NOT spelled '*foo' but merely 'foo'.
>
> and
>
> NAME: { 'type': TYPE, 'default': null }
> to
>
> NAME-PREFIXED-BY_ASKTERISK: TYPE
>
> if we think these abbreviations enhance schema readability enough to be
> worthwhile. The first one does, in my opinion. but I'm not so sure
> about the second one.
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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
