From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTvKS-00026w-Jy for qemu-devel@nongnu.org; Mon, 24 Aug 2015 13:14:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTvKP-0000Xc-CJ for qemu-devel@nongnu.org; Mon, 24 Aug 2015 13:14:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTvKP-0000WI-4z for qemu-devel@nongnu.org; Mon, 24 Aug 2015 13:14:37 -0400 References: <1438703896-12553-1-git-send-email-armbru@redhat.com> <1438703896-12553-31-git-send-email-armbru@redhat.com> <55D94951.3020109@redhat.com> <87egisq5xu.fsf@blackfin.pond.sub.org> <55DB1716.10502@redhat.com> <87twror5ha.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55DB50F7.8040909@redhat.com> Date: Mon, 24 Aug 2015 11:14:31 -0600 MIME-Version: 1.0 In-Reply-To: <87twror5ha.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FmvEi19NQ0UbICEICAfhfU5HC9BwWvwC6" Subject: Re: [Qemu-devel] [PATCH RFC v3 30/32] qapi: New QMP command query-schema for QMP schema introspection 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) --FmvEi19NQ0UbICEICAfhfU5HC9BwWvwC6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/24/2015 10:55 AM, Markus Armbruster wrote: > Our motivation for dropping nested structs was to avoid burning the > 'name': {} struct member syntax on a trivial and rarely used > convenience, and instead make it available for a way to specify member > attributes beyond name and type. >=20 > Is there a chance we want to define simple union cases with attributes > beyond tag value and type? You may have a valid point there. It's hard to predict the future, but leaving dictionary open for future use is the most extensible approach. But in the patches I'm currently working on, I had only been adding support for anonymous types for the branches of flat unions; I intentionally left simple unions to REQUIRE a type name for the branches (because of the way we create a wrapper type around the single data member for introspection purposes). >=20 > I think we have a better chance to answer that question after we clean > non-simple unions. Well, my proposed cleanup was figuring out a way to explicitly specify that for a given enum value, we add no additional members to the wire struct. But there is a possible alternative syntax for that: { 'union': 'Union', 'base': 'Base', 'discriminator': 'type', 'data': { 'branch1': 'AdditionalMembers', 'branch2': null } } which uses 'null' in place of '{}' for the explicitly empty case, while still requiring a type name for all other branches. I still think that requiring a user to explicitly list all branches of a union is a nice fail-safe (if the enum is extended, we are then reminded to update the union to match) that we don't currently have. >=20 >>> Both Abort and ChardevDummy exist only because you need a type to >>> declare a simple union case. I'd like to explore cleaning up the >>> convoluted union syntax first. If we then still have a need for >>> empty structs, we can consider optimizing them. >> >> And that's where my patches were headed - by allowing a dict instead o= f >> a type name for the branches of a flat union, the syntax for flat unio= ns >> becomes simpler, and allows us to sanely represent a >> "no-additional-members" variant without needing 'Abort' as an empty ty= pe. >=20 > Empty cases in flat unions are not a problem: simply don't mention the > tag value. But that's opposite of the direction I want to move, where we require all branches to be listed, but have a clean way to document the branches that add no additional members to the variant object. >=20 > I'd like to explore doing unions in schema syntax the way we represent > them internally and in introspection. Basically get rid of the "need t= o > inherit the common members from a base" nonsense. I've already posted patches that would allow: { 'union': 'Union', 'base': { ... }, 'discriminator': 'type', 'data': { ... } } that is, allowing the base fields to be specified inline as an anonymous struct rather than having to create a one-off named struct for that task.= https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02346.html But there's still the question of whether we want to always tie the union branches to an explicitly named enum, or whether it is nice to preserve the current simple union semantics that an implicit enum is created to cover all branches when an explicit enum type is not named. Conversely, I still want to get to the point that even a simple union can optionally document that it reuses an existing enum (along with the corresponding qapi-generator enforced rules that all enum branches are properly covered), rather than always being forced to use an implicit enum type (where mismatches between an intended explicit enum are too likely). >=20 > Once that's done, we can decice whether simple unions are still > worthwhile syntactical sugar. Agreed - there's still some room to play with things, and flushing our existing patch queue to have a stable base to play on will make it a bit nicer. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --FmvEi19NQ0UbICEICAfhfU5HC9BwWvwC6 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/ iQEcBAEBCAAGBQJV21D3AAoJEKeha0olJ0Nqte8H+QFfJ4usRfUrDlKb/xVBx/AC xrx69BNvsnO8FTpYnpciRM6DKQQw5PX7kUh60/5hK+s+ZDE19z2TnzAxb3D543Fk P09Bjwayv+qCWB4x9ILIbv+mA2sRk7Qoay/N2xWoaSID2d0hOBenXdkcZVivMt7b gts0G0xWpSBydHsED20uGusrfmX99sx/67h5vOOYmgmFSCJ3NMtLTG7PpCE206kF 5UTc0C/O7hM+V1WiPJ6xKiGarjPIUWWUDg00s043+OoqcCKTFfVFgvjsNbUylS3a 0QnVNs96+RJtVn2NpHVe33k7P2sCGonKmVWxSDkaLydJKGIuQo17c6M7wTAjz10= =ViRK -----END PGP SIGNATURE----- --FmvEi19NQ0UbICEICAfhfU5HC9BwWvwC6--