Bug 82127 - Add enum attribute to arg element to allow type safe protocol generation for languages that support enum as a type.
Summary: Add enum attribute to arg element to allow type safe protocol generation for ...
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: wayland (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-04 11:52 UTC by Erik De Rijcke
Modified: 2016-03-17 18:59 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Erik De Rijcke 2014-08-04 11:52:05 UTC 
Note that this suggestion is not the same as the one proposed in bug 55534.

Currently the protocol defines enums but does not specify any means of assigning those enums to arguments. The only way to deduce this is to read the documentation and hope you get it right.

This is ok if you're programming in C.

However a lot of other languages have a separate enum type that allows for type safe input of arguments that expect it. Unfortunately the wayland protocol xml does not link arguments that expect an enum value to the respective enum, making it impossible for these languages to fully facilitate their typesafe nature.

I propose to add an "enum" attribute to a "arg" elements that expect an enum. The value of the "enum" attribute will be the "name" value of the required "enum" element. This way the current C generator will not be impacted while allowing typesafe languages to use this extra piece of information.

example:

<enum name="error">
...
</enum>

<arg name="code" type="uint" enum="error"/>
Comment 1 Pekka Paalanen 2014-08-04 14:14:02 UTC 
The complication here is that we use enums as plain integers, which means also individual bits and sets of bits in bitfields.

The attribute would be good for making generated documentation link automatically to the right enum definitions, but for type safety it is not that simple. You probably need another attribute somewhere to say whether it is allowed 'or' the values together, even if the result is not listed in the enum.
Comment 2 Erik De Rijcke 2014-08-04 18:55:53 UTC 
In that case it's a matter of balancing protocol bloat with type safety I guess. Since an addition/change of protocol isn't easily done, I guess this wont happen soon...
Comment 3 Pekka Paalanen 2015-11-06 14:12:16 UTC 
I still haven't caught up on what landed with the enum patches in Wayland - is this issue now essentially fixed?
Comment 4 Erik De Rijcke 2015-11-06 14:29:23 UTC 
I guess it is. Everything described in the original post is/will be merged soon.

Remaining issues are not described here (open/closed enum) as I was not aware of that at the time and it will probably get another round of discussions before being fixed.
Comment 5 Erik De Rijcke 2015-11-06 14:29:55 UTC 
I guess it is. Everything described in the original post is/will be merged soon.

Remaining issues are not described here (open/closed enum) as I was not aware of that at the time and it will probably get another round of discussions before being fixed.
Comment 6 Bryce Harrington 2016-03-17 18:59:01 UTC 
Closing as resolved as per last few comments.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.