Re: [Qemu-devel] [PATCH v8 10/17] qapi: Simplify visiting of alternate types

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

On 11/04/2015 09:03 AM, Markus Armbruster wrote:

> Conclusions:
> 
> * Having two different name manglers is a headache we could do without,
>   especially since the second one camel_to_upper() is pretty magic.
> 
>   We have it only to get
> 
>     typedef enum BlockDeviceIoStatus {
>         BLOCK_DEVICE_IO_STATUS_OK = 0,
>         BLOCK_DEVICE_IO_STATUS_FAILED = 1,
>         BLOCK_DEVICE_IO_STATUS_NOSPACE = 2,
>         BLOCK_DEVICE_IO_STATUS_MAX = 3,
>     } BlockDeviceIoStatus;
> 
>   instead of
> 
>     typedef enum BlockDeviceIoStatus {
>         BlockDeviceIoStatus_ok = 0,
>         BlockDeviceIoStatus_failed = 1,
>         BlockDeviceIoStatus_nospace = 2,
>         BlockDeviceIoStatus_MAX = 3,
>     } BlockDeviceIoStatus;
> 
>   Bah!  CODING_STYLE doesn't even ask for shouting enumeration
>   constants.  Can't see why we do.

Interesting idea.  In fact, if we went one step further:

BlockDeviceIoStatus_ok = 0,
...
BlockDeviceIoStatusMAX = 3.

(that is, typename + '_' + value for user values, and typename + 'MAX'
for the sentinel), then the max value _cannot_ collide with any of the
other values.

> 
> * Keeping the complexity of the rules under control is good both for
>   qapi.py and for the QAPI schema language.
> 
>   To that end, I think we should consider reserving the same set of
>   names both for members and tag values.  It gets rid of complications
>   like enumerations you can't use as flat union tags.
> 
>   Additionally, the question whether to keep the door open for
>   generating an enum for the alternate cases becomes moot.
> 
> What do you think?

I like the idea. Don't know if it's too late for 2.5, though.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]