Enums, bitfields and wl_arrays

[Erik De Rijcke]

The enum discussion seems to become a lengthy one and it's becoming hard to
see the forest for the trees.

I'll give my input as a Java bindings dev. Please correct any bad
assumptions or observations I've made.

>From what I see in Auke's patches:

- 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.

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).

amen

On Thu, Oct 1, 2015 at 7:49 PM, Bryce Harrington <bryce at osg.samsung.com>
wrote:

> The topic of adding better enum/bitfield support to the protocol has
> come up a few[0] times[1] in the past, and again more recently[2].  We
> also have several proposed patches in patchwork, but I'm not sure they
> reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].
>
> From what I gather of the discussions, no one is really against this
> feature conceptually, and impementationally the discussions appear to
> have moved further afield.  It feels like we're real close to having
> something that could be landed, but it's not 100% clear to me what
> exactly to land.  Since it's a protocol types change I would prefer to
> make sure it has a strong consensus before landing it.
>
> I know that several people have proposed patches on this - Bill, Nils
> and Auke at least.  Since there's a definite need for this, and since
> agreement appears to be not far off, I would like to get this landed
> this release.  And ideally I'd like to get this landed early in the
> release so we give plenty of time for testing.
>
> Since Auke's patchset proposalis the most recent, let's take that one as
> the candidate for landing.  Gentlemen, I'd like to ask you to review
> these three patches [5,6,7] and either give your Reviewed-by's or flag
> specific improvements needed.  If you have a more conceptual
> disagreement, and don't think the patchset is landable as implemented,
> please raise that issue asap too.
>
> Bryce
>
> 0:
> http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html
> 1:
> http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html
> 2:
> http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html
>
> 3: http://patchwork.freedesktop.org/patch/47726/
> 4: http://patchwork.freedesktop.org/patch/47727/
> 5: http://patchwork.freedesktop.org/patch/53018/
> 6: http://patchwork.freedesktop.org/patch/53019/
> 7: http://patchwork.freedesktop.org/patch/53020/
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151003/b48b49ba/attachment.html>