Bug 55534

Summary:	[task] Protocol: Make enums a type for arguments
Product:	Wayland	Reporter:	John Kåre Alsaker <john.kare.alsaker>
Component:	wayland	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	enhancement
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	48976

Description John Kåre Alsaker 2012-10-02 12:48:07 UTC

Enums should be their own type so could specify that you are passing an enum by using type="enum.<enum name>". For the error event where any enum can be passed, we could use type="enum". When the enum is specified in another interface, we could use type="enum.<interface>.<enum name>". I'm not sure how this should interact with multiple versions or how it currently does. We could also just use type="enum" for these cases.

Adding enums as types serves as documentation and adds type safety for generated code in languages which features such for enums. The effect on C source and ABI should be none.

Comment 1 John Kåre Alsaker 2012-10-02 13:37:41 UTC

Given that enum are also used for bitfields, we should add a separate type for that. So I suggest we use type="enum" and type="flags", and reference the enum using enum="<enum-name>" and perhaps reuse the interface attribute to specify in which interface the enum resides.

Comment 2 John Kåre Alsaker 2012-10-02 13:52:58 UTC

Bitfield enums should be specified in a linear fashion. This makes the value attribute on enums less required, could that be removed or made optional?

I noticed that wl_shell_surface.resize is missing the values 3 and 7. Where those previously defined values? Could those be specified with an unsupported attribute instead of defining values?

Comment 3 Kristian Høgsberg 2012-10-02 13:58:19 UTC

(In reply to comment #2)
> Bitfield enums should be specified in a linear fashion. This makes the value
> attribute on enums less required, could that be removed or made optional?
> 
> I noticed that wl_shell_surface.resize is missing the values 3 and 7. Where
> those previously defined values? Could those be specified with an
> unsupported attribute instead of defining values?

The resize enum is laid out such that you can bitwise-or LEFT and BOTTOM and get LEFT_BOTTOM.

Comment 4 John Kåre Alsaker 2012-10-02 14:21:35 UTC

Oh, that should be a bitfield then. To maintain your precious backwards compatibility we could add none, top_left, bottom_left, top_right and bottom_right as presets. Say: <preset name="top_left" value="top left" />

Comment 5 Kristian Høgsberg 2012-10-02 14:39:22 UTC

(In reply to comment #4)
> Oh, that should be a bitfield then. To maintain your precious backwards
> compatibility we could add none, top_left, bottom_left, top_right and
> bottom_right as presets. Say: <preset name="top_left" value="top left" />

What problem are you trying to fix?

Comment 6 John Kåre Alsaker 2012-10-02 14:55:43 UTC

The problem of finding out which values are valid for arguments when reading protocol files and the lack of type safety when generating interfaces for other languages.

Comment 7 John Kåre Alsaker 2012-10-02 17:18:14 UTC

Note that adding this does not have to break backward compatibility with existing C source code, ABIs or protocol files. I just think that making these things higher level in the protocol files makes them easier to understand, and allows better code and documentation to be generated from them.

Comment 8 Kristian Høgsberg 2012-10-30 00:52:02 UTC

Not going to change this, what we have works well enough and we can document the use of enums where necessary.

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.