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
signature.asc
Description: OpenPGP digital signature
