<div dir="ltr">Adding enum members is backward compatible for Java. If you compile against an enum with 2 members, and later on a new member is added, you can simply use the new version of the enum.<div> </div><div>Important however is that the order of old members do not change when new members are added.</div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Oct 8, 2015 at 10:27 PM, Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, On 8 October 2015 at 21:13, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote: > On 5 October 2015 at 21:31, Victor Berger <<a href="mailto:victor.berger@m4x.org">victor.berger@m4x.org</a>> wrote: >> In this case, for a "closed" enum, the binding can decide to ignore any >> value received on the wire that is not described in the XML, as anyway, the >> client would not know what to do with it (and if they knew, they should be >> using a more recent version of the binding). > > This should never happen. The compositor is responsible for tracking > which version the client has bound, and not sending it values it > doesn't know what to do with. > > I've heard mention that xdg-shell allows this, but I also can't see it > anywhere in the spec. Jasper? Whoops ... 9:18 PM <Jasper> daniels, sorry, what were we talking about with enums? 9:20 PM <daniels> Jasper: people are concerned that xdg-shell has 'open' enums, in that a compositor can send a configure event with enum values unknown to the client 9:20 PM <Jasper> daniels, that's correct 9:20 PM <daniels> Jasper: bollocks, really? 9:20 PM <Jasper> daniels, <a href="http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n321" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n321</a> 9:23 PM <daniels> Jasper: ah, i see - that does make quite a bit of sense 9:23 PM <daniels> Jasper: but i do wonder if we should bound that by what the client actually supports, e.g. don't send gnome-specific values unless the client has bound gtk_shell 9:23 PM <Jasper> daniels, the state mechanism is designed to solve a very specific race condition, so we don't want people inventing their own protocols to do the same. 9:24 PM <daniels> Jasper: oh, indeed 9:24 PM <Jasper> daniels, I would be fine with that, but I'm not sure it helps Rust clients. 9:24 PM <daniels> Jasper: indeed, more of a general musing 9:24 PM <daniels> Jasper: thanks for pointing that out; not sure how i missed it How does that play with Java/Haskell/etc? Would that just degenerate into a plain undecorated uint, or ... ? Cheers, Daniel </blockquote></div> </div>