From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKCBo-0007PB-Vv for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:13:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKCBl-0001rK-P2 for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:13:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKCBl-0001qd-H1 for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:13:29 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-34-git-send-email-armbru@redhat.com> <55B11AF1.3000509@redhat.com> <87h9ooy71o.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55B7F072.8000706@redhat.com> Date: Tue, 28 Jul 2015 15:13:22 -0600 MIME-Version: 1.0 In-Reply-To: <87h9ooy71o.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XXuPj8OF3D9Gu4jMR98pBKdD1a6kfAeOL" Subject: Re: [Qemu-devel] [PATCH RFC v2 33/47] qapi: Clean up after recent conversions to QAPISchemaVisitor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XXuPj8OF3D9Gu4jMR98pBKdD1a6kfAeOL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/28/2015 03:18 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> On 07/01/2015 02:22 PM, Markus Armbruster wrote: >>> Drop helper functions that are now unused. >>> >>> Make pylint reasonably happy. >>> >>> Rename generate_FOO() functions to gen_FOO() for consistency. >>> >>> Use more consistent and sensible variable names. >>> >>> Consistently use c_ for mapping keys when their value is a C >>> identifier or type. >>> >>> Simplify gen_enum() and gen_visit_union() >>> >>> Consistently use single quotes for C text string literals. >> >> Not sure if it is worth splitting this into pieces. Fortunately, ther= e >> are no changes to generated output. >=20 > I'm afraid splitting would increase churn without much gain. If you > want me to split, I can try. I can live without the split; generated output being unchanged is already a good sign. >>> -def generate_command_decl(name, args, ret_type): >>> - arglist=3D"" >>> +def gen_command_decl(name, args, rets): >> >> I can see how 'args' is plural (even if it is a single string for the >> name of a type containing the args), but should it be 'ret' instead of= >> 'rets'? >=20 > I now realize readers may find this odd. >=20 > The QMP specification talks about command arguments and command > responses. >=20 > The QMP wire format uses 'arguments' and 'return'. >=20 > The schema language uses 'data' and 'returns'. Near-perfect score on > terminology inconsistency, as usual. Anyway, 'data' is plural (and a > rather unhelpful choice of syntax). 'returns' could either be the > plural of the noun "return", or the third person singular of the verb > "to return". >=20 > Permit me a philosophical digression. The common way to do functions i= n > programming is to have multiple arguments and a single return value. I= > believe this is mostly common machines' calling conventions leaking int= o > languages. From a more abstract point of view, there's no structural > difference between function arguments and values: both are simply an > element of an arbitrary set (domain and codomain, respectively). In > particular, both can be tuples. >=20 > It's perfectly sane to have functions take exactly one argument and > yield exactly one value. Some functional languages work that way. >=20 > But when both argument and value are generally tuples anyway, as they > are in QAPI/QMP, it's more natural to talk about arguments and return > values. I abbreviated to args and rets. There's method to my madness > ;) >=20 > I'm open to better ideas on terminology. Not sure I'm thinking of anything better; so while I found it unusual, the explanation helps and I certainly won't reject it as wrong. >>> -def generate_visit_struct_fields(name, members, base =3D None): >>> +def gen_visit_struct_fields(name, base, members): >>> struct_fields_seen.add(name) >> >>> - type=3Dbase.c_name(), c_name=3Dc_name('base')) >>> + c_type=3Dbase.c_name(), c_name=3Dc_name('base')= ) >> >> Possible churn here based on my earlier comments about c_name(constant= ) >> being constant. >=20 > I'm leaning towards leaving it as is just to keep the code similar to > other places generating visit_type_FOO() calls. And I already easily got rid of it in my followup RFC patches, so no problem if you leave it as is for the sake of getting this series in. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --XXuPj8OF3D9Gu4jMR98pBKdD1a6kfAeOL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVt/ByAAoJEKeha0olJ0NqUT0H/0t9sJa4k2rd2Ka2Z5uQHsYp +bTTaMYXEqeKvf9nBOOoOW9nU48d/pE6LHOQgQEck3lGAPc8n4HSN+LAPmVkjueI 0KASQ7LIDzAt+CNLec0Zs3Ij9GCYEoLQHbe6nJ4VeGtosyj0TDr2oj0naOIqaX4Q aoPON0NkkynRHljddtm/kyi8F2+Rt3+iF6LQcM8Kvp+M9Lm5m2mBC9QESnr7hc/C K+XK5QiFbbZmjXe7AaJc8ySo4HHsoQ36p2DpXUvBTsqdQ5fSruf6qh/xNVJnUBCf l1osIZ6g8RaXvxJlbOyfndUlbZZGGy7aUyvM2R61NGa5U+xb9zgdtckBNMzQuug= =y/+T -----END PGP SIGNATURE----- --XXuPj8OF3D9Gu4jMR98pBKdD1a6kfAeOL--