On 05/20/2014 03:07 AM, Fam Zheng wrote:
> Please first take a look at patch 7 to see what is supported by this series.
>
> Patch 1 ~ 3 allows some useful basic types in schema.
>
> Patch 4 ~ 6 implements the new syntax.
>
> Note: The introduced '@arg' sigil, just like the preexisting '*arg', is
> reducing the cleanness of the syntax. We should get rid of both of them in
> long
> term. Here, this series compromises on this and introduces '@arg' because:
>
> - We have to distinguish the argument property dictionary from nested
> struct:
>
> I.e.:
>
> 'data': {
> 'arg1': { 'member1': 'int', 'member2': 'str' }
> '@arg2': { 'type': 'int', 'default': 100 }
> }
>
> Until we completely drop and forbid the 'arg1' nested struct use case.
>
> - Forbidding 'arg1' it's doable, but doing it now means we pull in many
> distractive patches to this series.Question - since we WANT to get rid of nested struct, why not reverse the sense? Mark all existing nested structs (weren't there just three that we found?) with the '@' sigil, and let the new syntax be sigil-free. Then when we clean up the nesting, we are also getting rid of the bad syntax, plus the sigil gives us something to search for in knowing how much to clean up. But if you stick the sigil on the new code, instead of the obsolete code, then as more and more places in the schema use defaults, it gets harder and harder to remove the use of the sigil even if the nested structs are eventually removed. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
