Enums, bitfields and wl_arrays

[Nils Chr. Brause]

Hi,

On Sat, Oct 3, 2015 at 9:05 PM, Erik De Rijcke <derijcke.erik at gmail.com> wrote:
> - Defining an uint (bitfield) or int (single enum) in the xml for an enum
> argument is the wrong approach. It prescribes, not describes. In some
> languages eg Java, there is no such thing as an uint. What is important, is
> to know how many enum values you are allowed to pass in an enum argument.
> How this translates low level is an implementation detail (wire format). We
> don't define opcodes either. The wire format in then end, is implicitly
> defined by the C generator based on the argument type in the xml (for an
> enum arg, some cases use an array of shorts, some cases use a int
> bitfield.). It would be better to define that relationship.

While I totally agree here, I highly doubt that this will be changed.

> General concerns as a language binding dev:
>
> - The definition of an enum, at least in Java (and I assume in a lot of
> other languages too), is a fixed set of values that are know at compile
> time. This set is unmodifiable at runtime. This means no new values of an
> enum type can be (safely) added/defined at runtime. It seems to me this
> definition is ultimately incompatible with wayland enums for several
> reasons.
>
> First reason is the case of an 'open' enum, as seen in xdg-shell state. From
> my understanding, a client or server should be able to act on any 'open'
> enum value it receives over the wire, even if this value was not known at
> compile time. As such a generated binding can not simply map all unknown
> wire values to the same "UNKNOWN" language specific enum type as the raw
> value would be lost in such case. It also makes it impossible to send out
> any undefined raw value. An 'open' enum is thus impossible to implement
> using a (language specific) enum as type. The core reason being that a
> wayland 'open' enum is not really an enum but a set of pre-defined
> constants.
>
> The second reason is the case of the 'closed' enum, as seen in all other
> enum definitions. A 'closed' wayland enum does allow to be directly mapped
> to a language specific enum type. However there is still the case of enum
> values known only by the other side (=different protocol versions). Again
> the solution(s) for this are the same as the first reason. Map to an
> 'UNKNOWN" value and have your raw value lost, or pass on the raw value but
> loose your language enum type usage.
>
> Both concerns seem to have no relevance to wayland per se, and should simply
> be solved by the language binding. I believe this not to be the case as
> there is the open question (for me) on what should be considered as
> acceptable behaviour when dealing with wayland enums in language bindings.
> If it is acceptable to have your raw value lost for a 'closed' enum, but not
> for an open value, then the language binding must be able to deal with that
> appropriately. However for that it most know in some way when an enum is
> open, and when it is closed (either by implicit ruling, eg it's an array
> thus open, or explicitly through an xml attribute).

In C++ it is quite easy to deal with open enumerations and unknown
enumeration values. The 'enum class' in C++11 can be converted to and
from its underlying type (integer), so that the user still can emit
and receive values unknown to the bindings. Other languages would
probably need to come up with a similar mechanism.

Cheers,
Nils