From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Fux-0005wc-Jy for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:10:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Fuq-0001WJ-Af for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:10:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Fuq-0001WF-3F for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:10:16 -0400 From: Markus Armbruster References: <88a1cc0775d3d4f5262b31b9452f8acccc6bbb41.1434458391.git.DirtY.iCE.hu@gmail.com> <87oakeg4eo.fsf@blackfin.pond.sub.org> <1434530501.5549.23.camel@redhat.com> <87bngea8hi.fsf@blackfin.pond.sub.org> <55816405.7090502@gmail.com> <87bnge310y.fsf@blackfin.pond.sub.org> <55817DD8.6060605@gmail.com> Date: Wed, 17 Jun 2015 18:10:13 +0200 In-Reply-To: <55817DD8.6060605@gmail.com> (=?utf-8?B?IkvFkXbDoWfDsyBab2x0?= =?utf-8?B?w6FuIidz?= message of "Wed, 17 Jun 2015 16:02:00 +0200") Message-ID: <87d20u71ui.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= Cc: Kevin Wolf , Michael Roth , =?utf-8?B?TMOh?= =?utf-8?B?c3psw7M=?= Ersek , qemu-devel@nongnu.org, Gerd Hoffmann "K=C5=91v=C3=A1g=C3=B3 Zolt=C3=A1n" writes: > 2015-06-17 15:41 keltez=C3=A9ssel, Markus Armbruster =C3=ADrta: >> "K=C5=91v=C3=A1g=C3=B3 Zolt=C3=A1n" writes: >> >>> 2015-06-17 13:18 keltez=C3=A9ssel, Markus Armbruster =C3=ADrta: >>>> Copying Kevin because similar issues exist in the block layer. >>>> >>>> Gerd Hoffmann writes: >>>> >>>>> On Mi, 2015-06-17 at 09:50 +0200, Markus Armbruster wrote: >>>>>> Copying L=C3=A1szl=C3=B3 because his fingerprints are on OptsVisitor. >>>>>> >>>>>> "K=C5=91v=C3=A1g=C3=B3, Zolt=C3=A1n" 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=3D44100' 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=3D0 to set a.foo and b.foo, but foo=3Dx s= et >> 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=3D44100 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.