Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor

[Markus Armbruster]

"Kővágó Zoltán" <address@hidden> writes:

> 2015-06-17 15:41 keltezéssel, Markus Armbruster írta:
>> "Kővágó Zoltán" <address@hidden> writes:
>>
>>> 2015-06-17 13:18 keltezéssel, Markus Armbruster írta:
>>>> Copying Kevin because similar issues exist in the block layer.
>>>>
>>>> Gerd Hoffmann <address@hidden> writes:
>>>>
>>>>> On Mi, 2015-06-17 at 09:50 +0200, Markus Armbruster wrote:
>>>>>> Copying László because his fingerprints are on OptsVisitor.
>>>>>>
>>>>>> "Kővágó, Zoltán" <address@hidden> writes:
>>>>>>
>>>>>>> The current OptsVisitor flattens the whole structure, if there are
>>>>>>> same named
>>>>>>> fields under different paths (like `in' and `out' in `Audiodev'),
>>>>>>> the current
>>>>>>> visitor can't cope with them (for example setting
>>>>>>> frequency=44100' will set the
>>>>>>> in's frequency to 44100 and leave out's frequency unspecified).
>>>>>>>
>>>>>>> This patch fixes it, by the following changes:
>>>>>>> 1) Specifying just the field name will apply to all fields that has the
>>>>>>>      specified name (this means it would set both in's and out's
>>>>>>> frequency to
>>>>>>>      44100 in the above example).
>>>>
>>>> What if they have different types?
>>>>
>>>> What if one of them can't take the value?
>>>
>>> Currently it will error out, requiring the user to be more
>>> explicit. Probably not the best solution, but I can't really think of
>>> a better solution. (If we would ignore invalid values that would be
>>> very confusing imho.)
>>
>> Yes, we clearly don't want foo=0 to set a.foo and b.foo, but foo=x set
>> only a.foo, because the former can take any string, but the latter only
>> a number.
>>
>> Can we require the LHS to be unambiguous?
>
> Originally I designed it that way because it allows you to specify
> frequency=44100 and set both in.frequency and out.frequency.

Is it common to set both to the same value?

We could also default one to the other.  Not sure that's actually a good
idea.

>                                                              But this
> could also be the convenience feature that we not really need. I don't
> see any other downside of making it unambigous.

Good to know.

We've struggled with unforeseen aftereffects of cute convenience
features too much, and by now I'm quite reluctant to support them
without a really compelling reason.