<div dir="ltr">The enum discussion seems to become a lengthy one and it's becoming hard to see the forest for the trees.<div><br></div><div>I'll give my input as a Java bindings dev. Please correct any bad assumptions or observations I've made.</div><div><br></div><div>From what I see in Auke's patches:</div><div><br></div><div>- 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.</div><div><br></div><div>General concerns as a language binding dev:</div><div><br></div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>amen</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 7:49 PM, Bryce Harrington <span dir="ltr"><<a href="mailto:bryce@osg.samsung.com" target="_blank">bryce@osg.samsung.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The topic of adding better enum/bitfield support to the protocol has<br>
come up a few[0] times[1] in the past, and again more recently[2].  We<br>
also have several proposed patches in patchwork, but I'm not sure they<br>
reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].<br>
<br>
>From what I gather of the discussions, no one is really against this<br>
feature conceptually, and impementationally the discussions appear to<br>
have moved further afield.  It feels like we're real close to having<br>
something that could be landed, but it's not 100% clear to me what<br>
exactly to land.  Since it's a protocol types change I would prefer to<br>
make sure it has a strong consensus before landing it.<br>
<br>
I know that several people have proposed patches on this - Bill, Nils<br>
and Auke at least.  Since there's a definite need for this, and since<br>
agreement appears to be not far off, I would like to get this landed<br>
this release.  And ideally I'd like to get this landed early in the<br>
release so we give plenty of time for testing.<br>
<br>
Since Auke's patchset proposalis the most recent, let's take that one as<br>
the candidate for landing.  Gentlemen, I'd like to ask you to review<br>
these three patches [5,6,7] and either give your Reviewed-by's or flag<br>
specific improvements needed.  If you have a more conceptual<br>
disagreement, and don't think the patchset is landable as implemented,<br>
please raise that issue asap too.<br>
<br>
Bryce<br>
<br>
0: <a href="http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html" rel="noreferrer" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html</a><br>
1: <a href="http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html" rel="noreferrer" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html</a><br>
2: <a href="http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html" rel="noreferrer" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html</a><br>
<br>
3: <a href="http://patchwork.freedesktop.org/patch/47726/" rel="noreferrer" target="_blank">http://patchwork.freedesktop.org/patch/47726/</a><br>
4: <a href="http://patchwork.freedesktop.org/patch/47727/" rel="noreferrer" target="_blank">http://patchwork.freedesktop.org/patch/47727/</a><br>
5: <a href="http://patchwork.freedesktop.org/patch/53018/" rel="noreferrer" target="_blank">http://patchwork.freedesktop.org/patch/53018/</a><br>
6: <a href="http://patchwork.freedesktop.org/patch/53019/" rel="noreferrer" target="_blank">http://patchwork.freedesktop.org/patch/53019/</a><br>
7: <a href="http://patchwork.freedesktop.org/patch/53020/" rel="noreferrer" target="_blank">http://patchwork.freedesktop.org/patch/53020/</a><br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</blockquote></div><br></div></div>